Korzystanie pośrednie nową obawą użytkowników systemów ERP

Katgoria: ERP / Utworzono: 30 marzec 2017

Korzystanie pośrednie nową obawą użytkowników systemów ERP

Niedawno blady strach padł na użytkowników oprogramowanie SAP AG za sprawą pewnego procesu i wyroku: "Po niedawnym orzeczeniu brytyjskiego Sądu Najwyższego, który potwierdził prawo firmy SAP do naliczania opłat za pośrednie korzystanie z systemów SAP przy użyciu takich aplikacji innych firm jak Salesforce, WorkDay i QlikView, korzystanie pośrednie jest obecnie wymieniane przez klientów firmy SAP jako główna obawa w obszarze zarządzania licencjami SAP i kontrolowania ich kosztów...."

REKLAMA

Cóż to jest to „korzystanie pośrednie” i w czym problem?

In this instance, the third party systems are accessing the SAP environment, pulling data and often writing it back via a connection to the SAP environment. Here a “user” must be set up to gain access to the SAP system. On the surface then it can appear like only one user (or a small number of users) is performing actions on the SAP system. In reality though, the “user” will be performing far more tasks than is possible for a single person to undertake. (Źródło: SAP Audits – Is it impossible to gauge financial exposure? – IT Asset Knowledgebase)

Generalnie chodzi o to, że integrowane ze sobą aplikacje wymieniają dane i „zlecają sobie” usługi, i tu warto wiedzieć co (dane, logika aplikacyjna) jest chronione prawami autorskimi i co stanowi know how. Problem tkwi w poprawnym zdefiniowaniu przedmiotu (obiektu) przetwarzania, przedmiotu prawa autorskiego i tego co stanowi know-how.

W tekście Ochrona know-how organizacji analizowanej pisałem dość dokładnie o prawach autorskich i know-how. Tu kilka kluczowych pojęć.

USTAWA z dnia 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych mówi:

Art. 1. 1. Przedmiotem prawa autorskiego jest każdy przejaw działalności twórczej o indywidualnym charakterze, ustalony w jakiejkolwiek postaci, niezależnie od wartości, przeznaczenia i sposobu wyrażenia (utwór).

Art. 2.
1. Opracowanie cudzego utworu, w szczególności tłumaczenie, przeróbka, adaptacja, jest przedmiotem prawa autorskiego bez uszczerbku dla prawa do utworu pierwotnego.
2. Rozporządzanie i korzystanie z opracowania zależy od zezwolenia twórcy utworu pierwotnego (prawo zależne), chyba że autorskie prawa majątkowe do utworu pierwotnego wygasły. W przypadku baz danych spełniających cechy utworu zezwolenie twórcy jest konieczne także na sporządzenie opracowania.
2. (1) Ochroną objęty może być wyłącznie sposób wyrażenia; nie są objęte ochroną odkrycia, idee, procedury, metody i zasady działania oraz koncepcje matematyczne.

USTAWA z dnia 16 kwietnia 1993 r. o zwalczaniu nieuczciwej konkurencji, mówi, że:

Art. 11.
4. Przez tajemnicę przedsiębiorstwa rozumie się nieujawnione do wiadomości publicznej informacje techniczne, technologiczne, organizacyjne przedsiębiorstwa lub inne informacje posiadające wartość gospodarczą, co do których przedsiębiorca podjął niezbędne działania w celu zachowania ich poufności.

Tak więc mamy kluczowe pojęcie: utwór oraz know-how. Utworem jest unikalna treść zaś know-how to nieujawnione i chronione (!) informacje (treści) techniczne, organizacyjne lub gospodarcze.

Czym jest owo „pośrednie korzystanie z systemu SAP”? Drugi tekst wyjaśnia: „accessing the SAP environment, pulling data and often writing it back via a connection to the SAP environment. Here a “user” must be set up to gain access to the SAP system„. Czyli „pobieranie i zapisywanie danych”, użytkownik by mógł „tego dokonać” musi mieć dostęp Systemu SAP.

Jednak sam fakt istnienia dostępu i korzystania z niego, nie oznacza korzystania z cudzych wartości intelektualnych!

Najpierw model takiego przypadku:

Użytkownik bezpośredni Systemu to „standardowy”, licencjonowany użytkownik. Aplikacja pośrednicząca także korzysta z licencjonowanego dostępu (API). Jak, i z czego (i czy), korzysta Użytkownik pośredni Systemu?

Żeby wskazać to, z czego korzysta zewnętrzny użytkownik (aktor) Systemu, należy „zajrzeć” do wnętrza systemu. Architektura Systemu i integracji ma taką postać:

Na tym diagramie mamy trzy kluczowe elementy (tu artefakty) reprezentujące wartości intelektualne chronione prawem: Logika biznesowa, Zebrane dane i Strukturę danych. Logika biznesowa to sposób (metody) przetwarzania informacji (danych) zawarte w programie komputerowym, stanowią (mogą stanowić) know-how firmy, sam program komputerowy (jego treść) to ustalony utwór. Prawo autorskie chroni bazy danych (zebrane i uporządkowane dane) zaś struktura danych (projekt, model danych) to także utwór chroniony.

Zintegrowana z Systemem aplikacja korzysta z API Systemu. API standardowo pozwala np: na pobranie obiektu, wstawienie obiektu oraz wykonanie operacji z użyciem logiki biznesowej.

Zasadnicze pytanie brzmi: co w Systemie stanowi produkt „działalności twórczej o indywidualnym charakterze”? Na pewno jest to oprogramowanie jako takie oraz struktura (model) danych oraz baza danych, czyli zebrane dane (z uwagi na ich unikalną strukturę, model, w bazie danych). Jednak program realizuje określoną logikę biznesową (operacje na danych) i przetwarza określone obiekty biznesowe, czyli określone zestawy danych takie jak faktura czy dokument magazynowy WZ. Ogólnie operacje z użyciem Systemu (aplikacji) mają np. taką postać:

Jest to przykład możliwego dialogu użytkownika (aktor) z aplikacją (System). Dialog taki, niezależnie od stopnia komplikacji, będzie się składał z operacji będących logiką biznesową (czyli specyfiką dziedziny) lub techniczną (specyfiką technologii implementacji). Przedmiotem przetwarzania będą określone obiekty biznesowe (nazwane zestawy danych), komunikat na ekranie także może być takim obiektem (jeżeli tym komunikatem jest treść dokumentu a nie tylko tekst mówiący, że coś zostało wykonane np. bez błędu).

Tu jednak mamy do czynienia z oprogramowaniem wspierającym między innymi operacje opisane w ustawach (księgowe). Niewątpliwie prawo chroni strukturę danych, dane zebrane w bazie danych oraz know-how, to które jest nieznane „innym”. Jednak prawo nie chroni idei, nie chroni też tego co „jest powszechnie znane”. Warto także wiedzieć, że wdrożenie w toku którego miała miejsce tak zwana kastomizacja, „wnosi” know-how przyszłego użytkownika do kodu, i za korzystanie z tej logiki dostawca oprogramowania nie ma prawa brać wynagrodzenia. Pod warunkiem jednak, że kod realizujący to wniesione know-how jest jawnie wydzielony!

Nie ma jednoznacznej odpowiedzi na pytanie czy w danym przypadku ma miejsce korzystanie pośrednie z oprogramowania, niewątpliwie sam fakt integracji nie stanowi korzystania pośredniego. Nie jest tez prawdą, ze sam fakt integracji automatycznie implikuje korzystanie pośrednie wymagające opłaty licencyjnej. Kluczem do stwierdzenia tego jest wiedza o architekturze systemu, o architekturze całości integracji i o tym jakie operacje i gdzie są wykonywane. Na szczęście to dostawca Systemu musi uzasadnić swoje roszczenia dotyczące własności intelektualnej, jednak korzystający z tego Systemu – jeżeli nie potrafi podać kontrargumentów – nie jest w stanie się obronić. Niestety największym problemem jest wdrożenie polegające na kastomizacji, gdyż dochodzi do „wplecenia” nowej logiki biznesowej do już istniejącej w dostarczanym oprogramowaniu.

Skutek jest taki, że dostawca oprogramowania ma podstawy prawne do ochrony kodu jaki dostarczył, jednak kupujący nie ma żadnych podstaw (dokumenty, projekt itp.) by chronić swoje know-how i by nie płacić za swoje własne know-how „włożone” w toku wdrożenia, do wdrażanego oprogramowania.

Dlatego warto restrykcyjnie prowadzić proces analizy i projektowania, to jest umiejętnie udokumentować projekt tak, by granica pomiędzy wartościami intelektualnymi dostawcy i nabywcy oprogramowania była jasno określona. I nie jest to rola prawnika a architekta całości systemu, który musi także znać i rozumieć prawne aspekty tej architektury.

Źródło: www.it-consulting.pl

Najnowsze wiadomości

Customer-specific AI: dlaczego w 2026 roku to ona przesądza o realnym wpływie AI na biznes

W 2026 roku sztuczna inteligencja przestaje być ciekawostką technologiczną, a zaczyna być rozliczana z realnego wpływu na biznes. Organizacje oczekują dziś decyzji, którym można zaufać, procesów działających przewidywalnie oraz doświadczeń klientów, które są spójne w skali. W tym kontekście coraz większe znaczenie zyskuje customer-specific AI - podejście, w którym inteligencja jest osadzona w danych, procesach i regułach konkretnej firmy, a nie oparta na generycznych, uśrednionych modelach.

Czytaj całość

PROMAG S.A. rozpoczyna wdrożenie systemu ERP IFS Cloud we współpracy z L-Systems

PROMAG S.A., lider w obszarze intralogistyki, rozpoczął wdrożenie systemu ERP IFS Cloud, który ma wesprzeć dalszy rozwój firmy oraz integrację kluczowych procesów biznesowych. Projekt realizowany jest we współpracy z firmą L-Systems i obejmuje m.in. obszary finansów, produkcji, logistyki, projektów oraz serwisu, odpowiadając na rosnącą skalę i złożoność realizowanych przedsięwzięć.

Czytaj całość

SkyAlyne stawia na IFS dla utrzymania floty RCAF

SkyAlyne, główny wykonawca programu Future Aircrew Training (FAcT), wybrał IFS Cloud for Aviation Maintenance jako cyfrową platformę do obsługi technicznej lotnictwa i zarządzania majątkiem. Wdrożenie ma zapewnić wgląd w czasie rzeczywistym w utrzymanie floty, zasoby i zgodność, ograniczyć przestoje oraz zwiększyć dostępność samolotów szkoleniowych RCAF w skali całego kraju. To ważny krok w modernizacji kanadyjskiego systemu szkolenia załóg lotniczych.

Czytaj całość

Wykorzystanie AI w firmach rośnie, ale wolniej, niż oczekiwano. Towarzyszy temu sporo rozczarowań

Wykorzystanie sztucznej inteligencji w firmach rośnie, ale tempo realnych wdrożeń pozostaje znacznie wolniejsze od wcześniejszych oczekiwań rynku. Dane pokazują, że z rozwiązań AI korzysta dziś wciąż niewiele przedsiębiorstw, a menedżerowie coraz częściej wskazują na bariery regulacyjne, koszty oraz brak powtarzalnych efektów biznesowych. W praktyce technologia jest testowana głównie w wybranych obszarach, a kluczowe decyzje nadal pozostają po stronie człowieka. Również w firmach, które wdrożyły AI, nierzadko towarzyszą temu rozczarowania.

Czytaj całość

Europejski przemysł cyfryzuje się zbyt wolno – ERP, chmura i AI stają się koniecznością

Europejski przemysł średniej wielkości wie, że cyfryzacja jest koniecznością, ale wciąż nie nadąża za tempem zmian. Ponad 60% firm ocenia swoje postępy w transformacji cyfrowej jako zbyt wolne, mimo rosnącej presji konkurencyjnej, regulacyjnej i kosztowej. Raport Forterro pokazuje wyraźną lukę między świadomością potrzeby inwestycji w chmurę, ERP i AI a realną zdolnością do ich wdrożenia – ograniczaną przez braki kompetencyjne, budżety i gotowość organizacyjną.

Czytaj całość

RAPORT ERP

Katalog rozwiązań IT

Katalog firm

Najnowsze artykuły

5 pułapek zarządzania zmianą, które mogą wykoleić transformację cyfrową i wdrożenie ERP

Dlaczego jedne wdrożenia ERP dowożą korzyści, a inne kończą się frustracją, obejściami w Excelu i spadkiem zaufania do systemu? Najczęściej decyduje nie technologia, lecz to, jak organizacja prowadzi zmianę: czy liderzy biorą odpowiedzialność za decyzje czy tempo jest dopasowane do zdolności absorpcji oraz czy ludzie dostają klarowność ról i realne kompetencje. Do tego dochodzi pytanie: co po go-live - stabilizacja czy chaos w firmie? Poniżej znajdziesz 5 pułapek, które najczęściej wykolejają transformację i praktyczne sposoby, jak im zapobiec.

Czytaj całość

SAP vs Oracle vs Microsoft: jak naprawdę wygląda chmura i sztuczna inteligencja w ERP

Wybór systemu ERP w erze chmury i sztucznej inteligencji to decyzja, która determinuje sposób działania organizacji na lata — a często także jej zdolność do skalowania, adaptacji i realnej transformacji cyfrowej. SAP, Oracle i Microsoft oferują dziś rozwiązania, które na pierwszy rzut oka wyglądają podobnie, lecz w praktyce reprezentują zupełnie odmienne podejścia do chmury, AI i zarządzania zmianą. Ten artykuł pokazuje, gdzie kończą się deklaracje, a zaczynają realne konsekwencje biznesowe wyboru ERP.

Czytaj całość

Transformacja cyfrowa z perspektywy CFO: 5 rzeczy, które przesądzają o sukcesie (albo o kosztownej porażce)

Transformacja cyfrowa w finansach często zaczyna się od pytania o ERP, ale w praktyce rzadko sprowadza się wyłącznie do wyboru systemu. Dla CFO kluczowe jest nie tylko „czy robimy pełną wymianę ERP”, lecz także jak policzyć ryzyko operacyjne po uruchomieniu, ocenić wpływ modelu chmurowego na koszty OPEX oraz utrzymać audytowalność i kontrolę wewnętrzną w nowym modelu działania firmy.

Czytaj całość

Agentic AI rewolucjonizuje HR i doświadczenia pracowników

Agentic AI zmienia HR: zamiast odpowiadać na pytania, samodzielnie realizuje zadania, koordynuje procesy i podejmuje decyzje zgodnie z polityką firmy. To przełom porównywalny z transformacją CRM – teraz dotyczy doświadczenia pracownika. Zyskują HR managerowie, CIO i CEO: mniej operacji, więcej strategii. W artykule wyjaśniamy, jak ta technologia redefiniuje rolę HR i daje organizacjom przewagę, której nie da się łatwo nadrobić.

Czytaj całość

Composable ERP: Przewodnik po nowoczesnej architekturze biznesowej

Czy Twój system ERP nadąża za tempem zmian rynkowych, czy stał się cyfrową kotwicą hamującą rozwój? W dobie nieciągłości biznesowej tradycyjne monolity ustępują miejsca elastycznej architekturze Composable ERP. To rewolucyjne podejście pozwala budować środowisko IT z niezależnych modułów (PBC) niczym z klocków, zapewniając zwinność nieosiągalną dla systemów z przeszłości. W tym raporcie odkryjesz, jak uniknąć pułapki długu technologicznego, poznasz strategie liderów rynku (od SAP po MACH Alliance) i wyciągniesz lekcje z kosztownych błędów gigantów takich jak Ulta Beauty. To Twój strategiczny przewodnik po transformacji z cyfrowego "betonu" w adaptacyjną "plastelinę".

Czytaj całość