Temat: Metodyka wytworzenia produkty analizy biznedsowej
Jarek Żeliński:
Aleksander Olszewski:
Dlatego bardzo mnie ciekawi, w jaki sposób twoja metodyka sprawia, że know how firmy jest chroniony? Owszem można przekazać prawa do dokumentacji. Wtedy firma może z niej korzystać. Ale stwierdzenie, że jest chroniona wiedza na temat rozwiązań firmy jest lekkim nadużyciem.[/i]
nie tyle "moja metodyka" jako taka a doprowadzenie opisu do "wystarczająco szczegółowej postaci".
Po pierwsze uwaga: to, że ktoś się czegoś dowiedział nie znaczy, że nabył jakiekolwiek prawa do tej"wiedzy". Klasyczny przykład: system scoringowy banku jako "metoda analizy ryzyka" nie podlega ochronie ale "szczegóły algorytmów oraz wag" użyte w tym systemie już tak. Zwróć uwagę, ze dotyczy to także wystarczająco dobrze opisanych procedur ISO stanowiących chroniona prawem tajemnicę służbową firmy.
Tu już pisałem, że można opatentować np. sposób wykorzystania algorytmu ale nie algorytm. Prawo patentowe jest bardziej restrykcyjne niż autorskie. Tak więc tu się zgadza. Jeśli dostawca i klient nie podpiszą odpowiedniej umowy o ochronie tajemnicy firmowej i nie zcedują tej odpowiedzialności kaskadowo w dół, nie ma co się rozwodzić o tajemnicy firmowej --- jej po prostu nie ma. Procedury ISO, jako normy, z tego co pamiętam, nie są ani opatentowane, ani nie są chronione prawem autorskim. Każdy może wprowadzić normę ISO w firmie, ale musi wydać szmal, jeśli chce mieć certyfikat.
I tu chyba dochodzimy do sedna. Jeśli mówimy o tajemnicy firmowej, wszystko zaczyna brzmieć ok. Konsekwencje takiej zmiany są takie, że o ile prawo autorskie chroni każde naruszenie prawa, o tyle raz ujawniona tajemnica firmowa nie może już stanowić tajemnicy. Dlatego te lojalki są takie dziwne.
Generalnie mamy dwa obszaru ochrony:
- Tajemnica przedsiębiorstwa. Jest chroniona na mocy USTAWY z dnia 16 kwietnia 1993 r. o zwalczaniu nieuczciwej konkurencji
- treść opracowań na mocy USTAWY z dnia 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych.
Tak więc jeżeli w wyniku analizy biznesowej powstanie dokument, jest on chroniony prawe autorskim. Projekt logiki oprogramowania opisany szczegółowo ale także - co bardzo ważne - JEDNOZNACZNIE, jest chroniony jako "algorytm" (prawo autorskie) albo (lub także) jako tajemnica przedsiębiorstwa. Developer, realizujący implementację takiego projektu, nie ma prawa takiego projektu wykorzystać powtórnie u innego klienta.
Proponowałbym nie używać słowa algorytm. Algorytmy są wyjęte z tego prawa, inaczej nikt nie mógł by programować. Metoda działania, pomysł na biznes ok., ale nawet idea nie jest chroniona prawem.
Zgadza się to, że jednoznaczna i szczegółowa dokumentacja daje ochronę przez prawo autorskie. Odpowiednie umowy mogą przenosić prawo autorskie od autora do nabywcy prawa, ale i tak np. dożywotnio autor ma prawo podpisywać swoim imieniem przedmiot prawa autorskiego :) Nie zmienia to faktu, że algorytmy (powiedzmy te bardziej matematyczne) nie podlegają ochronie tak samo jak diagramy. I tu wkracza ochrona tajemnicy firmy i ta ustawa (o ile klient coś takiego wystosuje) i konsekwencje, które z tego wynikają. Np. autor diagramu nieopatrznie pochwali się tym diagramem publicznie i konkurencja śmiało może go wykorzystać --- tajemnica firmowa prysła. Autor nieźle oberwał, konkurencja lojalki nie podpisywała, a diagram nie jest chroniony prawem autorskim.
To jest potencjalnie słaba strona szczegółowego opisu diagramem (BPMN) procesów firmy. Dlatego zaciekawił mnie ten punkt metodyki. Z tego właśnie powodu są opory w firmach przez szczegółową analizą procesów przez osoby trzecie.
To jak z domem, nie da się chronić pomysłu "miejsce zamieszkania w postaci domku jednorodzinnego" ale konkretny projekt architektoniczny jest chroniony.
To się zgadza. Ale projekt jako komplet dokumentacji. Wizualizacja domku jest chroniona na poziomie binarnym. Jeśli ktoś na podstawie wizualizacji "skopiuje" rozwiązanie i opracuje własną dokumentację projektową (przykład SAS i WP) prawo autorskie jest tu (słusznie) bezsilne.
W przypadku przytoczonej "afery" nie podlega w oprogramowaniu ochronie sama kokretna funkcjonalność jako wymaganie funkcjonalne (i bardzo dobrze) ale szczegóły jej konkretnej implementacji już tak (by tych może być wiele, lepszych i gorszych.
Tak więc "moja metodyka" (zresztą podejście takie jest stosowane na świecie) to tak dobrana szczegółowość udokumentowania projektu dla klienta, by spełniał on powyższe rygory i dał się "chronić prawem przed powielaniem". Drugim koronnym założeniem jest tu uznanie, że "aby taka ochrona interesów klienta była możliwa ani autorem ani współautorem projektu, nie może być wykonawca (firma IT, żyjąca z tego), bo wtedy to on dysponuje tym prawem i ma interes w tym by nim dysponować.
Tu jest kolejny poważny problem. Przy jasno określonych oczekiwaniach klienta, prace analityczne stanowią słuszną część projektu (niekiedy do 40% czasu i mogą kosztować od 20% do 40% budżetu). Tak na oko, jeśli się mylę popraw mnie.
Znakomita większość firm (jak nie wszystkie), taką dokumentację (o ile ją wykonuje inna firma niż dostawca oprogramowania) księgują jako OPEX, czyli w bieżącym roku rozliczeniowym. System natomiast, jako CAPEX, z reguły z amortyzacją na 5 lat. Co zważywszy na koszt pieniądza i duży wkład w wydatki firmy kosztu sporządzenia analizy może znacznie obniżyć rentowność firmy, co nie wszystkim się spodoba.
Moim zdaniem jest to istotny argument przeciw (co nie oznacza, że podzielam ten pogląd) dla biznesu na rozbijanie prac projektowych na analityczne i implementacyjne.
Np. pewna firma, znany w Polsce światowy dostawca ERP, wpisuje sobie do umów, że wszelkie pomysły na nowe funkcjonalności jakie zostaną zrealizowane podczas kastomizacji, przechodzą na ich własność nawet jeśli ich współautorem jest zamawiąjacy. Ze mną mieli problem, bo wydzieliłem w projekcie swoją rolę jako projektanta nowych "ficzerów" i ich implementacji i dostawca mógł wyłącznie na bazie projektu (musi to być szczegółowy model obiektowy!) wykonać implementacje ale już nie może oferować tego nikomu innemu (w szczególności konkurentom mojego klienta). To, że zna projekt nie daje mu do niego żadnego prawa do niego.
Tu jest właśnie ta sytuacja, że nie zgodziłeś się na przeniesie swoich praw autorskich na wykonawcę i słusznie. Natomiast zamawiający może nałożyć ochronę tajemnicą firmową wyniki analiz. Wtedy miałbyś problem z realizacją podobnego projektu u ich konkurenta. Z czystej ciekawości zapytam, czy zdarzył Ci się taki przypadek?
Był to dla nich bardzo trudny moment w negocjacjach... ale wyszło na moje :)
Dyskusja się zrobiła bardzo ciekawa. Niestety nadal nie widzę sposobu ochrony procesów przedsiębiorstwa (proponujesz ich analizę) bez podpisania lojalki :), a lojalka to nie to samo co prawo autorskie.
пропозиції роботи
