Skutek jest taki, że dostawca oprogramowania na 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.
Na wstępnie należy się czytelnikowi pewne wyjaśnienie: kim jest prawnik? Słownik języka polskiego podaje: prawo 1. ?ogół przepisów i norm prawnych regulujących stosunki między ludźmi danej społeczności? 2. ?norma prawna? 3. ?nauka o prawie, studia nad prawodawstwem? 4. ?uprawnienia przysługujące komuś zgodnie z obowiązującymi przepisami? 5. ?zasada rządząca procesami przyrodniczymi i społecznymi, stanowiąca cel badań naukowych? 6. ?kierunek studiów związanych z nauką o prawie, z prawoznawstwem? Pojęcie "prawnik" jest używane generalnie w dwóch znaczeniach: (1) osoba znająca prawo w rozumieniu przepisów i norm prawnych np. danego kraju oraz (2) osoba zajmująca sie nauką jaką jest prawo, studiami…
Bardzo często spotykam się z projektami inicjowanymi przez średnie kadry kierownicze dużych firm i urzędów, często mają one pewną wspólną cechę: "nie możemy nic zmieniać w strategii organizacji ale chcemy usprawnić pracę w naszym wydziale". To z reguły bardzo cenna inicjatywa ale także dobra droga do porażki projektu. W urzędach często na granicy łamania prawa... a nie raz z jego łamaniem. Projekty w administracji publicznej mają dodatkową specyfikę: zasady ustala prawodawca a nie menedżer organizacji. Bardzo dobrze opisał to zjawisko prof. Bolesław Szafrański wskazując przyczynę wielu porażek wdrożeń w administracji.…
Niedawno pisałem (Instrukcja dla prawników...) o tym, że prawnicy to nie inżynierowie. Nie był to przytyk, a zwykłe wskazanie na fakt, że to po prostu rożne kompetencje. Problem prawa autorskiego w obszarze szeroko pojętej inżynierii jest bardzo trudny, nie jest to "wiedza humanistyczna". Podejście prawników z reguły jednak bazuje na humanistycznej wiedzy tychże. Poniżej cytat pewnego bloga: Utwór architektoniczny należy moim zdaniem zakwalifikować (albo traktować analogicznie w tej kwestii) do szeroko rozumianych dzieł plastycznych. Te ostatnie bowiem, w przeciwieństwie np. do utworów muzycznych lub wyrażonych słowem, dużo ściślej związane są…
Dwa lata temu pisałem o mikroserwisach: Obecnie mamy już dość dobrze wypracowane wzorce projektowe ale nadal jest problem ze zrozumieniem ?kiedy i jak?. Ładnie to opisał swego czasu E.Evans przy okazji wzorca DDD, Tu poprzestanę jedynie na pojęciu bounded context czyli ?granica kontekstu?. Granica ta ma podwójne znaczenie: kontekst nadaje (zmienia) znaczenia w modelu pojęciowym (bałwan w kontekście zimy to co innego niż bałwan w kontekście członków zespołu projektowego) oraz kontekst (bardzo często) wyznacza zakres projektu (inne aspekty wzorca DDD tu pominę). Pierwsza uwaga: kontekst dziedzinowy (pojęciowy) jest ważniejszy (powinien…
Jako partner merytoryczny Raportu zapraszam do lektury... PERSPEKTYWY ERP 2017Wzorem ubiegłego roku oddajemy do Państwa dyspozycji materiał stanowiący podsumowanie działań kluczowych dostawców rozwiązań wspomagających zarządzanie przedsiębiorstwem w 2016 r. oraz prezentację kierunków rozwoju oferowanych systemów ERP w roku bieżącym. Mamy nadzieję, iż zaprezentowane wypowiedzi będą dodatkowym argumentem przy wyborze partnera w działaniach zmierzających do optymalizacji i podniesienia efektywności posiadanych zasobów IT w roku 2017. Źródło: PERSPEKTYWY 2017 - ERP-view.pl - ERP, CRM, MRP, Business Intelligence, MRP
