Prawie dwa lata temu pisałem:
Pewien lider na rynku dostawców systemów ERP, ma zapis w umowie mówiący, że przejmuje prawa autorskie do całości pomysłów i kodu (funkcjonalności) jaki powstaną podczas prac z klientem nad dostosowaniem dostarczanego systemu ERP (czyli tak zwana kastomizacja). Czyli know-how zamawiającego idzie do konkurencji ? firma ta chwali się na rynku, że ma referencyjne branżowe rozwiązania ?
Byli bardzo zaskoczeni (i wściekli) gdy dowiedzieli się, że zgodnie z umową analizę i projekt implementacji (model PIM) nowych funkcjonalności, których nie ma ich ERP, robię ja. Ich tłumaczenie, że tylko oni maja wiedzę by to robić bo to ich ERP było nie do obrony: pokazałem im opis ich własnego systemu, jego metodyki wdrożenia i informację, że jest wykonany znanym narzędziem i w znanej technologii, i że projekt jaki ode mnie dostaną będzie wystarczający i prawidłowy by go zaimplementować w tym ERP. Niestety, tu nie przejęli wiedzy i pomysłów zamawiającego. Tak się da zrobić, trzeba nie dać się szantażować swojemu własnemu dostawcy.
To dlatego dostawcy Ci (nie tylko ERP i inne gotowe systemy, także firmy tworzące oprogramowanie dedykowane) zrobią wszystko, by zastana u klienta analiza poszła do kosza i naciskają na to, by analizę wymagań (przedwdrożeniową) powtarzać rękami ich pracowników. Nie prawdą jest, że analizę wymagań może poprawnie zrobić wyłącznie dostawca oprogramowania. Dostawca gotowego systemu ma wykonać analizą pokrycia wymagań przez dostarczane przez siebie oprogramowanie (opisana tu kiedyś analiza gap/fit). Deweloperzy, dostawcy spokojnie mogą wykonać implementację wymaganych nowych funkcjonalności na bazie poprawnego projektu. Problem mają w tym, że wtedy nie mogą go przejąć. (Prawo autorskie, szpiegostwo przemysłowe i projektowanie).
Artykuł ten stale na budzi wiele kontrowersji i pytań oraz sprzeciwów, głównie jednak ze strony dostawców oprogramowania. Obserwuje inny ciekawy symptom: kupujący systemy ERP wierzą, że dostawca oprogramowania ERP w jakiś cudowny sposób naprawi ich firmę i należy się go słuchać. Zresztą prawie każdy dostawca ERP tak mówi. To także jest mit. Artykuł ten dotyczy nieuczciwych praktyk a nie “wszystkich dostawców oprogramowania ERP”.
Zaczynam dostrzegać coraz większe podobieństwo pomiędzy korporacjami farmaceutycznymi i dostawcami kompleksowych systemów ERP, jedni i drudzy twierdzą, że:
- kupując ich produkt gdy Cię boli, ból przejdzie,
- kupując ich produkt gdy Cię jeszcze nie boli, nie zaboli Cię w przyszłości (inni biorą, ich nie boli), po zażyciu nie ma możliwości sprawdzenia co by było gdybyśmy nie zażywali ale mówią, że na wszelki wypadek należy zażywać (słynne reklamy witamin, suplementów diety a nawet pasty do zębów),
- nie trzeba iść do lekarza na konsultacje, nasze produkty kupisz bez nich (bez recepty),
- jeżeli ktoś mówi, że nasze lekarstwo nie działa to na pewno kłamie, nie słuchaj go,
- owszem, wielu ludzi po zażyciu naszych leków miało kłopoty, niektórzy zmarli, ale to tylko dlatego, że nie czytali ulotki.
Dostrzegam także to, że wielu menedżerów daje się szantażować dostawcom ERP, którzy zaraz po podpisaniu umowy zaczynają stawiać warunki jakby zapominali kto komu i za co płaci. Zresztą bardzo często są to umowy o bardzo złej treści, gorąco odradzam zawieranie umów z dostawcami oprogramowania tylko ze wsparciem własnych prawników na bazie wzoru umowy dostawcy oprogramowania. Z całym dla nich szacunkiem, Wasi prawnicy są na pewno specjalistami z Waszej branży czy prawa gospodarczego, ale mało który ma doskonałe obycie w branży IT i prawie autorskim. Na tej niewiedzy żerują dostawcy oprogramowania, którzy często szantażują swoich klientów licencjami i ograniczeniami dostępu do kodu.
Jak zapanować nad dostawcą
Najpierw krótki opis tego co Państwo kupujecie. Poniżej struktura każdego dobrze zaprojektowanego oprogramowania:
A więc krótko, żeby nie zanudzać: Każde oprogramowanie jest mniej lub bardziej gotowe (zaryzykuje, że jest gotowe w ponad 90%), dotyczy to także tak zwanego oprogramowania dedykowanego. Oprogramowanie w całości dedykowane różni się od tak zwanego gotowego tylko tym, że nie ma jeszcze “Logiki biznesowej dostarczonej”. Dostawca oprogramowania w zasadzie musi zrobić dwie rzeczy: skonfigurować środowisko, które dostarcza w tym ewentualnie integrowane oprogramowanie (powyżej wszytko to co niebieskie) oraz stworzyć kod jeszcze nie istniejący czyli Logikę biznesową dedykowaną (implementacja). W przypadku dostawcy pakietu ERP tej gotowej logiki jest na prawdę bardzo dużo.
I teraz:
- Dostawca udzieli Ci licencji na wszystko co niebieskie, tu należy sprawdzić czy jest autorem wszystkiego (co jest mało prawdopodobne) czy tylko części.
- Najgłupszym pomysłem jest zgoda na dostosowywanie Logiki dostarczonej do swoich potrzeb bo:
- jest to bardzo kosztowne (ingerencja w ogromny istniejący kod wymaga bardzo dużo zmian w tym testów)
- całe Twoje know-how staje się własnością dostawcy oprogramowania, Twoja Logika biznesowa wzbogaciła kod dostawcy, praktycznie nie możesz zabronić jej dalszej sprzedaży.
- Najlepszym pomysłem jest wcześniejsze udokumentowanie i zawarcie w kontrakcie oddzielnej części oprogramowania: Logiki biznesowej dedykowanej, do której zachowujesz pełnię praw i absolutnie nie przekazujesz tych praw wykonawcy oprogramowania, to że napisał ten kod na bazie dokumentacji jaką mu dostarczysz, nie daje developerowi żadnych praw do tej części kodu (Logiki biznesowej dedykowanej, ale to wymaga dobrze napisanej umowy!) gdyż wtedy programista tworzy utówr zależny i nie nabywa do niego żadnych praw, w umie należy dodatkowo zawrzeć klauzulę o ochronie know-how. Wiem, że większość programistów mówi, że to nie prawda, zapewniam Cie, że mam rację – sprawdzone w praktyce.
Gdzie tkwi podstęp: Logika Biznesowa Dedykowana MUSI być udokumentowana osobno w sposób jednoznaczny, nie dający programiście pola do własnej interpretacji, a to wymaga opisania tego metodami formalnymi. Logika biznesowa dedykowana musi być odrębnym TWOIM kodem (w umowie prawa majątkowe do niego oraz umowa o ochronie Twojego know-how). Ale to podobno dużo kosztuje! Nie, dostawca oprogramowania z reguły i tak na Twój koszt to w jakiejś formie zrobi! Dodatkowo praktyka pokazuje, że zaprojektowanie i wykonanie odrębnej Logiki biznesowej dedykowanej, kosztuje zawsze mniej (nie raz znacznie mniej!) niż koszt dostosowywania ogromnej istniejącej już logiki dostarczonej. Większość kupujących systemy ERP z powodu braku tej wiedzy i pod naciskiem dostawcy oprogramowania, przyjmuje niekorzystną dla siebie metodę wdrożenia i podpisując wcześniej niekorzystną dla siebie umowę (kastomizacja oprogramowania). Większość wdrożeń jest prowadzona w sposób, który odradzam, owszem ale (ten cytat dla dociekliwych) większość firm IT dorada właśnie kastomizację:
…powszechność jakiegoś poglądu to bardzo słaby, by nie rzec – żaden dowód jego prawdziwości. Powszechne bywają chociażby mity, które ex definitione nie mają nic wspólnego z prawdą. […]
Dlatego właśnie Sokrates przywiązywał tak wielką wagę do tego, aby precyzyjnie i jednoznacznie definiować terminy i pojęcia, jakich używamy w dyskusji i odrzucać to, co w naszym ich rozumieniu jest przypadkowe, niepewne i stanowi efekt nie naszej faktycznej wiedzy, lecz jedynie podzielanego z innymi ludźmi stereotypu dotyczącego przedmiotu rozmowy. (Czy powszechność jakiegoś poglądu jest wprost proporcjonalna do jego prawdziwości?).
I na koniec: wybierając gotowe oprogramowanie na prawdę nie ma sensu wypisywanie setek wymagań. Należy zrezygnować z wielodniowych wywiadów i spisywania setek życzeń. Lepszym podejściem jest analiza tego jak organizacja działa, zidentyfikowanie obszarów “standardowych” oraz tych, które są Państwa “specjalnością” (Logika biznesowa dedykowana), potem wybrać najbardziej pasujący pakiet oprogramowania i nauczyć się go używać (wdrożyć do użycia). Brakującą logikę zlecić jako dedykowany pod-projekt (ale na bazie wcześniej wykonanego dla siebie projektu) i stać się właścicielem powstałego oprogramowania. Podejście polegające na uznaniu, że nowe oprogramowanie należy dostosować do potrzeb użytkowników z reguły kończy się sprowadzeniem nowego, nie raz bardzo wartościowego, oprogramowania do tego co stare i znane i to na koszt kupującego z bardzo miernym skutkiem.
Witam Panie Jarku
Ciekawy artykuł zwłaszcza dla kogoś, kto tak jak ja reprezentuje firmę wdrażającą systemy ERP.
W poruszanym przez Pana zagadnieniu jak to zawsze bywa są dwie strony medalu.
Zajmujemy się wdrażaniem systemów ERP w firmach z sektora MSP (raczej średnich niż małych).
Praktycznie w każdym wdrożeniu pojawia się element związany z uzupełnieniem standardowego ERP o dodatkowe funkcjonalności a najczęściej całe moduły.
Podczas wdrożeń skupiamy się przede wszystkim na optymalizacji procesów jakie występują w firmach i takim wdrożeniu systemu aby te procesy realizował.
I tu spotykamy się z sytuacją dotyczącą rozbieżności oczekiwań.
W firmach z którymi współpracujemy często świadomość i wiedza biznesowa w pewnych obszarach są na dość podstawowym poziomie. Oczekiwania wobec efektów wdrożenia systemu artykułowane są na poziomie ogólnych życzeń.
Praktycznie na podstawie własnych doświadczeń, wykształcenia i dostępnej wiedzy projektujemy i wdrażamy konkretne procesy w danej firmie, które prowadzą do realizacji tych życzeń.
Jednocześnie nasi Klienci często domagają się tego aby kod źródłowy i logika powstałych modułów był ich własnością bez prawa wykorzystania w innych firmach.
I tu pojawia się pytanie czy logika jakiegoś procesu, która jest opisana w stosownych podręcznikach, może zostać zastrzeżona przez Klienta?
Czy proces, który został przez nas opracowany od początku do końca czy też rozwiązania techniczne wymyślone przez nas i zastosowane do napisania aplikacji mogą być z automatu własnością Klienta?
Według nas nie do końca.
Aby rozwiązać tą sytuację po wykonaniu analizy, jeszcze przed podpisaniem umowy na wykonanie staramy się wyraźnie poinformować Klienta o możliwości wykorzystania powstałych modułów także w innych firmach.
Po takim, jasnym postawieniu sprawy najczęściej sytuacja kończy się w ten sposób, że Klient wskazuje, który konkretny element rozwiązania nie może być wykorzystany w innych firmach.
Dodatkowo proponujemy Klientowi udział w przychodach, ze sprzedaży powstałej aplikacji do innych podmiotów.
Wydaje nam się być to uczciwym postawieniem sprawy i znajduje zrozumienie u Klientów.
W kwestii “wiedzy zarządczej” wielu firm pozostaje mi się zgodzić, ale od pewnego czasu “rozgrzeszam” te zarządy, których firmy osiągają dobre wyniki, w końcu do jazdy samochodem nie trzeba rozumieć fizyki silnika spalinowego, ale do jego jakiejkolwiek modyfikacji już tak…
Klienci mają 100% racji, gdy “domagają się tego aby kod źródłowy i logika powstałych modułów był ich własnością bez prawa wykorzystania w innych firmach.” ale pod warunkiem, że mowa o “ich własnych, niestandardowych” pomysłach i potrafią to wykazać.
Dalej:
– Czy logika jakiegoś procesu, która jest opisana w stosownych podręcznikach, może zostać zastrzeżona przez Klienta?
[jz] Jeżeli jest “podręcznikowa” to jasne, że nie i to jest Logika biznesowa dostarczona (w kodzie lub dokumentacji), z której klient może skorzystać gdy zapłaci za dany moduł.
– Czy proces, który został przez nas opracowany od początku do końca czy też rozwiązania techniczne wymyślone przez nas i zastosowane do napisania aplikacji mogą być z automatu własnością Klienta?
[jz] I tu pojawia się problem, bo po pierwsze co tak na prawdę zostało opracowane? Opracowanie samego modelu (dokumentacji) “tego co klient robi” nie jest twórczą działalnością, więc nie jest “Wasze”. Owszem forma, postać, może być Waszym dziełem (np. diagramy BPMN, metodyka analizy), nie zmienia to jednak faktu, że “proces” jest procesem klienta, podobnie jak fotograf, który wykona portret, bez zgody fotografowanego (prawa do wykorzystania wizerunku) nie ma żadnego prawa dysponowania tym zdjęciem mimo, że osobiście je wykonał. W kwestii rozwiązania technicznego nie ma problemu, jest to zawsze Wasze.
Problem widzę gdzie indziej: ta część Waszej usługi, która stanowi niejako “doradztwo strategiczne i zarządcze” dla klienta (opracowany nowy lub zoptymalizowany proces) także powinna przejść na własność klienta, bo to dla niego powstało i z jego inicjatywy (ale to już kwestia treści umowy).
Problemy jakie widzę u klientów polegają na tym, że oni nie raz mają swoje bardzo dobrze wypracowane “metody pracy” ale nie potrafią ich “dobrze udokumentować” (a tylko takie know-how jest prawnie chronione). Prawda jest taka, że od strony uczciwości kolejność jest taka:
1. Klient ma (powstało) udokumentowane swoje “procesy i algorytmy”,
2. Dostawca na bazie tej dokumentacji tworzy nowy moduł z Logika dedykowaną,
3. Klient udziela licencji wykonawcy (o ile wyrazi taka wolę) na jakiekolwiek dalsze wykorzystanie tego modułu (a nie odwrotnie).
Tak więc (formalnie) jest tu dokładnie odwrotnie niż Pan napisał.
Dalej. Jeżeli analizę i doradztwo wykonana pracownik dostawcy oprogramowania (Wy) to prawa autorskie osobiste pozostają trwale przy firmie (a konkretnie pracodawca konsultanta a nie sam konsultant) więc ta wiedza tam i tak formalnie zostaje. Jedyną bezpieczną wersją dla klienta jest uzyskanie praw majątkowych do dedykowanych mu modułów i ich dokumentacji i wysoka kara umowna dla wykonawcy za ewentualne ujawnienie/powielenie zdobytego w projekcie know-how Klienta.
Kolejny problem to ograniczenia konkretnej platformy/systemu ERP. Skoro analizę i projekt realizuje się dopiero po wyborze konkretnego produktu i zawarciu umowy, Klient nie ma pojęcia czy wybrał optymalne dla siebie rozwiązanie, gorzej – w zasadzie nie może się z tego wycofać. Drugi problem to to, że dostawca konkretnego produktu zawsze forsuje użycie dostarczonych a nie optymalnych rozwiązań co jest zresztą naturalne.
Z perspektywy Klienta optymalną sytuacją jest taka, w której zanim zostanie wybrane jakiekolwiek rozwiązanie powstanie dokumentacja opisująca tę firmę i logikę jej działania. Prawa majątkowe do tego opracowania powinny być w rękach tej firmy (to ich “zdjęcie”). Z tą dokumentacją szuka się pakietu ERP, który ma najlepiej pasującą Logikę biznesową dostarczoną. Logika biznesowa dedykowana powstanie w przypadku gdy okaże się, że będzie to konieczne.
Panie Jarku dziękuję za komentarz.
Mam jednak jeszcze kilka wątpliwości.
Napisał Pan że:
“I tu pojawia się problem, bo po pierwsze co tak na prawdę zostało opracowane? Opracowanie samego modelu (dokumentacji) ?tego co klient robi? nie jest twórczą działalnością, więc nie jest ?Wasze?”.
A co jeśli dane procesy u Klienta jeszcze nie istnieją? Po prostu tego do tej pory nie robił.Przyjmijmy np. że uruchamia sklep internetowy, gdzie wszystkie procesy dotyczące sposobu rejestracji, logowania, bezpieczeństwa, płatności itp pochodzą od nas. Od Klienta dostajemy tylko informację, że chce aby sklep działał tak jak ten wskazany przez niego (najczęściej konkurencyjny) plus sugestie dotyczące strony wizualnej.
Drugie zagadnienie. Napisał Pan:
“Problem widzę gdzie indziej: ta część Waszej usługi, która stanowi niejako ?doradztwo strategiczne i zarządcze? dla klienta (opracowany nowy lub zoptymalizowany proces) także powinna przejść na własność klienta, bo to dla niego powstało i z jego inicjatywy (ale to już kwestia treści umowy).”
Co znaczy przejść na własność Klienta? Czy to oznacza, że nie mogę innemu Klientowi doradzać w ustawieniu procesu realizującego takie same funkcje jak ten zrealizowany u pierwszego Klienta?
I ostatnie zagadnienie:
Napisał Pan, że:
“Prawda jest taka, że od strony uczciwości kolejność jest taka:
1. Klient ma (powstało) udokumentowane swoje ?procesy i algorytmy?,
2. Dostawca na bazie tej dokumentacji tworzy nowy moduł z Logika dedykowaną,
3. Klient udziela licencji wykonawcy (o ile wyrazi taka wolę) na jakiekolwiek dalsze wykorzystanie tego modułu (a nie odwrotnie).
A co jeśli ustalenie z Klientem przed wykonaniem danego moduły, chęci jego wykorzystania do dalszej sprzedaży pozwoli temuż Klientowi uzyskać znaczne obniżenie kosztów jego realizacji. Są sytuacje gdzie temat do wykonania jest na tyle ciekawy, że opłaca nam się w niego zainwestować i wykonać go nawet poniżej kosztów, po to aby móc go sprzedać innym Klientom.
Czy złożenie takiej propozycji Klientowi jest nieuczciwe? Tym bardziej że Klient i tak zastrzega co bezwzględnie nie może się pojawić w “wersji handlowej”.
Najczęściej jest tak, że firmy z danej branży lub o takim samym modelu biznesowym działają podobnie. O przewadze konkurencyjnej danego podmiotu decyduje często mały element i ten element właśnie zastrzega Klient.
W efekcie Klient ma niższe koszty realizacji projektu, profity od sprzedaży “swojego” modułu do innych Klientów a my rozwiązanie, które pomaga nam w dalszej sprzedaży do kolejnych Firm.
Jak Pan zapewne zauważył Panie Jarku wśród firm w Polsce działa taki ciekawy mechanizm:
– z jednej strony chcą One zastrzec wszystko to co się dla Nich robi nawet jeśli jest to pewnym standardem branżowym
– z drugiej strony poszukują wykonawców, którzy mają doświadczenie w danej branży licząc, że taki wykonawca ma już gotowe rozwiązania (aplikacje)dla ich branży.
Występuje tu chyba lekka sprzeczność.
Powyżej napisał Pan same prawdziwe rzeczy :). W kwestii powstających “nowych rzeczy” to mamy tu wbrew pozorom proste pytanie: kto komu i na jakiej zasadzie zleca. Pamiętajmy, że mamy w prawie cywilnym (co jest moim zdaniem logiczne) dwa rodzaje umów:
1. umowa rezultatu czy umowa o dzieło
2. umowa starannego działania czyli umowa zlecenia
Na Pana pytania trudno odpowiedzieć, bez wiedzy jaką umową zawiera Pan z klientem. Możemy mieć w zasadzie do czynienia z trzema wariantami:
1. Dostawca oprogramowania zawiera z klientem umowę o dzieło, wtedy prawa do dzieła przechodzą na zamawiającego, jednak to poza kodeksem cywilnym w grę wchodzi prawo autorskie (raporty z prac analitycznych oraz oprogramowanie traktowane są przez prawo jak dzieła literackie, wartości intelektualne w nich zawarte jako know-how)
2. Dostawca oprogramowania może zawrzeć z klientem umowę zlecenia (np. większość umów pod tytułem “agile”), wtedy wytwór tej pracy z zasady należy do zleceniodawcy.
3. Klient, przed zawarciem umowy z dostawcą oprogramowania, dysponuje dokumentami analitycznymi, wtedy dostawca wykonuje prace podobna do pracy tłumacza (pomijam tu kwestie technologiczne).
Czy może Pan innemu klientowi doradzać? Oczywiście, że może Pan klientom doradzać, ale musi Pan pamiętać, że jeżeli jest jakaś wiedza (np. opisany jakiś proces lub reguły biznesowe), którą klient zastrzegł w umowie jako jego tajemnice przedsiębiorstwa, to nie może Pan już tej “wiedzy branżowej” przekazać kolejnym klientom. Znowu wkraczamy w kwestie treści umów. Dlatego zawsze mówię swoim klientom: treść umowy jest kluczem. Mój artykuł mówi o nieuczciwych i nieetycznych praktykach a nie o “zakazach”.
Jeżeli w umowie ustali Pan z klientem, że ten daje Panu prawa do korzystania z pomysłu w zamian za obniżenie ceny to jest to tylko kwestia negocjacji i ustalenia (mamy swobodę zawierania umów ;)). Ważne jest by jasno było określone kto jakimi prawami intelektualnymi dysponuje (a tu jest niestety cieniutko w wielu umowach).
To co Pan na końcu nazwał “lekką sprzecznością” tak na prawdę jest “szarym” szpiegostwem przemysłowym: wiele firm wybiera firmy doradcze lub wdrożeniowe kierując się przy ich wyborze tym, czy świadczyły one wcześniej usługi ich głównym konkurentom. Wkraczamy tu znowu na pole etyki firm doradczych i wdrożeniowych i samych kupujących także (po tej stronie także jest masa nieuczciwości). Pytanie jakie tu się pojawia: czy Państwo jako firma, pomagacie w tym “szpiegostwie” swoim klientom?