Business Knowledge Blueprints

Ronald G. Ross 

Ronald G. Ross jest auto­rem lub współ­au­to­rem wie­lu opra­co­wań na temat mode­li poję­cio­wych i zarzą­dza­nia wie­dzą . Jest tak­że współ­za­ło­ży­cie­lem Business Rule Solution LLC, oraz współ­twór­cą spe­cy­fi­ka­cji i nota­cji SBVR .

Książka

Najnowsze z powyż­szych opra­co­wań to rodzaj pod­su­mo­wa­nia pew­nej czę­ści dorob­ku autora.

Modele poję­cio­we są czę­sto mylo­ne z pro­jek­to­wa­niem rela­cyj­ne­go mode­lu danych, a bywa gorzej, gdy są utoż­sa­mia­ne z mode­lem dzie­dzi­ny sys­te­mu” w pro­jek­tach doty­czą­cych two­rze­nia apli­ka­cji okre­śla­nych jako„obiektowe”.

Książka trak­tu­je o mode­lach poję­cio­wych, i autor defi­niu­je je jako: 

model poję­cio­wy: upo­rząd­ko­wa­ny zbiór pojęć i związ­ków mię­dzy nimi

Podstawowym związ­kiem mię­dzy poję­cia­mi (nazwa­mi) jest fakt (pre­dy­kat: zwią­zek zda­nio­twór­czy) łączą­cy poję­cia w popraw­ne i praw­dzi­we zdania. 

Przykład: poję­cia «pies» oraz «listo­nosz» to nazwy słow­ni­ko­we. Połączone fak­tem (pre­dy­ka­tem) two­rzą zda­nie, np.: „ «Pies» szcze­ka na «listo­no­sza» ” (z uwzględ­nie­niem pol­skiej flek­sji, «szcze­ka (na)» to fakt – pre­dy­kat). Jest to zda­nie popraw­ne a tak­że zda­nie praw­dzi­we: jest praw­dą, że pies szcze­ka na listo­no­sza” (to rela­cja), albo: jest moż­li­we, że pies szcze­ka na listo­no­sza” (jest praw­dą to, że to może się to wyda­rzyć). Ważna rzecz: poję­cia to nie sło­wa, to to co opi­su­ją defi­ni­cje tych pojęć (patrz: trój­kąt semio­tycz­nysemio­ty­ka).

Budowanie takich zdań to kon­tro­la (testo­wa­nie) popraw­no­ści mode­lu poję­cio­we­go, test spój­no­ści, kom­plet­no­ści i nie­sprzecz­no­ści mode­lu poję­cio­we­go. Poprawny model poję­cio­wy (name­spa­ce) to pod­sta­wo­wy waru­nek np. póź­niej­szej spój­no­ści całe­go sys­te­mu zarzą­dza­nia infor­ma­cją (tak­że dany­mi), doku­men­ta­mi (gro­ma­dzą dane), meta­da­ny­mi (opi­su­ją dane). 

Podtytuł książ­ki to: About Vocabulary & Concept Models (O słow­nic­twie i mode­lach poję­cio­wych). Warto wie­dzieć, że zna­ko­mi­ta więk­szość nie­uda­nych pro­jek­tów i wdro­żeń opro­gra­mo­wa­nia to sku­tek błę­dów w mode­lach poję­cio­wych (nazew­nic­two).

Nazewnictwo to nie tyl­ko nazwy doku­men­tów, tabel i pól (ety­kiet danych), to tak­że same dane czy­li nazwy sta­no­wią­ce war­to­ści pól for­mu­la­rzy: nazwy miast, nazwi­ska, nazwy przed­mio­tów, pro­duk­tów, itp. Dawno temu już skoń­czy­ły się cza­sy, gdy kom­pu­te­ry tyl­ko liczy­ły” (to wte­dy powsta­ła idea rela­cyj­ne­go mode­lu danych). Obecnie kom­pu­te­ry prze­twa­rza­ją dane nie będą­ce licz­ba­mi, dane niestrukturalne. 

Zarządzanie wie­dzą to nie są obliczenia.

Autor pisze: akt two­rze­nia danych (zapi­sy­wa­nie infor­ma­cji) to akt komu­ni­ka­cji: to prze­kaz (wia­do­mość) dla przy­szłych czy­tel­ni­ków, odbior­ców tych danych. Dlatego komu­ni­kat (treść), musi (powi­nen) być zro­zu­mia­ły i jed­no­znacz­ny. Jedynym spo­so­bem zagwa­ran­to­wa­nia tego jest popraw­ność uży­te­go zaso­bu pojęć (słow­nic­twa). To wła­śnie jest miej­sce na ana­li­zy i pro­jek­to­wa­nie: naj­pierw mode­li poję­cio­wych a potem mode­li i struk­tur danych. 

Pewną wadą moim zda­niem jest wpro­wa­dze­nie przez auto­ra nowej sym­bo­li­ki dla gene­ra­li­za­cji (budo­wa­nie tak­so­no­mii) w posta­ci pogru­bio­nej linii”. Jednak każ­dy kto zna UML i pozna SBVR, moim zda­niem, bez pro­ble­mu sobie z tym pora­dzi (Visual Paradigm tak wła­śnie zro­bił: gene­ra­li­za­cje na mode­lach fak­tów obra­zo­wa­ne są jako strzał­ki z zamknię­tym gro­tem, zna­ne z UML, podej­ście to opi­su­je Dodatek C do spe­cy­fi­ka­cji SBVR). 

Modele pojęciowe

Modele poję­cio­we są bar­dzo czę­sto mylo­ne z mode­lem pro­ce­sów. Jest to kon­se­kwen­cja sto­so­wa­nia związ­ków skie­ro­wa­nych (aso­cja­cje skie­ro­wa­ne w UML, mode­le poję­cio­we są wyra­ża­ne jako kon­tek­sto­we dia­gra­my klas). Zdanie pies szcze­ka na listo­no­sza” to nie pro­cess (biz­ne­so­wy), to zda­nie spraw­dza­ją­ce popraw­ność uży­tych nazw (pies, listo­nosz) i rozu­mie­nia tych pojęć (komu­ni­kat) oraz praw­dzi­wość zda­nia jako takie­go. Przykład: 

Diagram fak­tów nota­cji SBVR, przy­kład wery­fi­ka­cji pojęć pies i listo­nosz oraz zda­nia pies szcze­ka na listo­no­sza”. (dia­gra­my opra­co­wa­ne z uży­ciem Visual Paradigm).

Powyższy dia­gram zawie­ra dwa poję­cia słow­ni­ko­we: pies, listo­nosz (for­mal­nie powin­ny być tak­że w słow­ni­ku i mieć swo­je jed­no­znacz­ne defi­ni­cje). Górna część dia­gra­mu to gra­ficz­na for­ma, omó­wio­ne­go wyżej, zda­nia pies szcze­ka na listo­no­sza”. Typowe zda­nia to co naj­mniej dwie nazwy połą­czo­ne pre­dy­ka­tem (fak­tem: szcze­ka­nie to fakt). Dolna część dia­gra­mu to zda­nie zbu­do­wa­ne z jed­nej nazwy i pre­dy­ka­tu: Pies szcze­ka”. To tak­że jest popraw­ne zda­nie. Metoda i sys­tem nota­cyj­ny, two­rze­nia mode­li poję­cio­wych (opar­ta na logi­ce pre­dy­ka­tów) zosta­ła opi­sa­na i opu­bli­ko­wa­na jako stan­dard SBVR (patrz tak­że OWL: Web Ontology Language) .

Autor w książ­ce dokład­nie opi­su­je róż­ni­cę mię­dzy mode­lem poję­cio­wym a mode­lem danych: model poję­cio­wy i model danych do róż­ne modele!

Model danych i model poję­cio­wy to nie to samo!

Autor poka­zu­je tak­że zasto­so­wa­nie dia­gra­mów fak­tów do mode­lo­wa­nia ontologii.

Na zakończenie

Słownik jest bar­dzo waż­ny bo sta­no­wi fun­da­ment logi­ki biz­ne­so­wej wyra­żo­nej w posta­ci reguł biz­ne­so­wych (busi­ness rules, patrz arty­kuł z 2015 roku: Reguły biz­ne­so­we, decy­zje i poję­cia). Autor dokład­nie opi­su­je meto­dy two­rze­nia słow­ni­ków i dia­gra­mów fak­tów, w dodat­kach jest omó­wio­ny przy­kład kom­plet­ne­go mode­lu wraz ze słow­ni­kiem. Tu, jako uzu­peł­nie­nie, pole­cam książ­kę prof. Hołówki o logi­ce i two­rze­niu defi­ni­cji pojęć .

Gorąco zachę­cam do lek­tu­ry tej książ­ki, moim zda­niem jest to typo­wa pozy­cja must have” dla każ­de­go ana­li­ty­ka i pro­jek­tan­ta sys­te­mów infor­ma­cyj­nych. Więcej na ten temat napi­sa­łem w 2016 roku w arty­ku­le: Model poję­cio­wy, model danych, model dzie­dzi­ny sys­te­mu.

Literatura

Ronald G. Ross. (2020). Business Knowledge Blueprints Enabling Your Data to Speak the Language of the Business (2nd Edition). Business Ruless Solution LLC.
OMG​.org. (2019). Semantics of Business Vocabulary and Business Rules. 334.
OMG​.org. (2014, September). Ontology Definition Metamodel (ODM).
Al-Fedaghi, S. (2020). Conceptual Modeling of Time for Computational Ontologies. 14.
Hołówka, T. (2012). Kultura logicz­na w przy­kła­dach (Wydawnictwo Naukowe PWN, Ed.). Wydawnictwo Naukowe PWN.
Ross, R. G. (2013). Business rule con­cepts: get­ting to the point of know­led­ge (4th Ed). Business Rule Solutions.
Ross, R. G., & Lam, G. S. W. (2011). Building busi­ness solu­tions: busi­ness ana­ly­sis with busi­ness rules. Business Rule Solutions.

Practical Event-Driven Microservices Architecture

Practical Event-Driven Microservices Architecture Building Sustainable and Highly Scalable Event-Driven Microservices

Hugo Rocha ma pra­wie dzie­się­cio­let­nie doświad­cze­nie w pra­cy z wyso­ce roz­pro­szo­ny­mi, ste­ro­wa­ny­mi zda­rze­nia­mi archi­tek­tu­ra­mi mikro­ser­wi­sów. Obecnie jest sze­fem inży­nie­rii w wio­dą­cej glo­bal­nej plat­for­mie ecom­mer­ce dla pro­duk­tów luk­su­so­wych (Farfetch), świad­czą­cej usłu­gi dla milio­nów aktyw­nych użyt­kow­ni­ków, wspie­ra­nej przez archi­tek­tu­rę ste­ro­wa­ną zda­rze­nia­mi z set­ka­mi mikro­ser­wi­sów prze­twa­rza­ją­cych set­ki zmian na sekun­dę. Wcześniej pra­co­wał dla kil­ku refe­ren­cyj­nych firm tele­ko­mu­ni­ka­cyj­nych, któ­re prze­cho­dzi­ły od apli­ka­cji mono­li­tycz­nych do archi­tek­tur zorien­to­wa­nych na mikro­ser­wi­sy. Hugo kie­ro­wał kil­ko­ma zespo­ła­mi, któ­re każ­de­go dnia bez­po­śred­nio sty­ka­ją się z ogra­ni­cze­nia­mi archi­tek­tur ste­ro­wa­nych zda­rze­nia­mi. Zaprojektował roz­wią­za­nia dla kry­tycz­nych ele­men­tów wyso­ce roz­pro­szo­nej plat­for­my bac­kof­fi­ce, obsłu­gu­ją­cej set­ki zmian na sekun­dę, współ­bież­nie, ska­lo­wal­nie i z wyso­ką wydajnością.

Ten opi­so­wy prze­wod­nik prze­pro­wa­dzi Cię przez eta­py prze­no­sze­nia plat­for­my z milio­na­mi użyt­kow­ni­ków z archi­tek­tu­ry mono­li­tu do archi­tek­tu­ry ste­ro­wa­nej zda­rze­nia­mi z wyko­rzy­sta­niem mikro­ser­wi­sów. Poznasz wyzwa­nia i zło­żo­no­ści, któ­re poja­wia­ją się w śro­do­wi­skach o dużej prze­pu­sto­wo­ści, zawie­ra­ją­cych czę­sto set­ki mikro­ser­wi­sów. Książka ta zosta­ła zapro­jek­to­wa­na jako naj­lep­sze źró­dło wie­dzy o tym, jak sto­so­wać archi­tek­tu­rę ste­ro­wa­ną zda­rze­nia­mi w rze­czy­wi­stych sce­na­riu­szach i ofe­ru­je set­ki wzor­ców do poko­na­nia powszech­nych i nie tak powszech­nych wyzwań.

Source: Practical Event-Driven Microservices Architecture | SpringerLink

Diagram: Jeden model dwa konteksty Diagram przedstawia obiekty biznesowe - dokumenty () pochodzące z dwóch różnych kontaktów. Na schemacie mamy trzy klasyfikatory reprezentujące dokumenty i ich struktury. W celu usunięcia kolizji pojęć opisanej przez Fowlera (FOWLER 2014) obiekty funkcjonujące w dwóch różnych kontaktach zostały rozdzielone na dwie kontekstowe przestrzenie pojęciowe: Sprzedaż oraz Serwis. W kontekście Sprzedaż pojęcia Klient i Produkt zostały użyte do nazwania obiektów biznesowych będących przedmiotami mającymi tożsamość. W kontekście Serwis pojęcia te (klient i produkt) ca jedynie cechami (atrybutami) obiektu biznesowego Uszkodzenie, słowa te (pojęcia) stanowią jedynie nazwy atrybutów a konkretne nazwy klienta i produktu stanowią wartość tych atrybutów i jako obiekty nie mają tu tożsamości (value UML i value object w DDD). Tak więc problem kolizji nazewnictwa została rozwiązany, warto tu zwrócić, że zbudowanie jednej spójnej relacyjnej bazy danych dla wszystkich pojęć obu tych dziedzin jest niemożliwe bez dodatkowych zabiegów z nazewnictwem.

Modelowanie architektury HLD i LLD usług aplikacji – modelowanie podsystemów

Wstęp

Tym razem krót­ki arty­kuł na temat pew­nej cie­ka­wej kon­struk­cji. Została ona opi­sa­na przez Rebekę Wirfs-Brock w 1999 roku . Pomysł nie zdo­był sobie wte­dy raczej zbyt dużej popu­lar­no­ści, jed­nak obec­nie, w dobie wzor­ców opar­tych o mikro­ser­wi­sy i mikro apli­ka­cje, ma szan­sę wró­cić do łask. Ja sto­su­ję go już od pew­ne­go cza­su. Skróty HLD i LLD to odpo­wied­nio: High-Level Design (pro­jekt wyso­kie­go pozio­mu) i Low-Level Design (pro­jekt niskie­go pozio­mu). Są to pozio­my abs­trak­cji w mode­lu PIM. 

Czytaj dalej… Modelowanie archi­tek­tu­ry HLD i LLD usług apli­ka­cji – mode­lo­wa­nie pod­sys­te­mów”

Marsz ku klęsce – Poradnik dla projektanta systemów

Lektura na Nowy Rok… Co praw­da wyda­na w 2007 roku, ale wła­śnie sobie o niej przypomniałem.. 

Ta książ­ka Yourdona leży u mnie na pół­ce nie­mal­że od dnia jej wyda­nia, gdy ją przy­pad­kiem upo­lo­wa­łem, zaraz po jej uka­za­niu się w księ­gar­niach. Napisanie o niej odkła­dam od lat, bo prak­tycz­nie nie ma tam obraz­ków UML, opi­sów wzor­ców itp.. Od jej prze­czy­ta­nia mówię sobie: jutro o niej napi­szę… i to trwa­ło do tego momentu.

To książ­ka w cało­ści napi­sa­na pro­zą, bez obraz­ków, w któ­rej autor dzie­li sie swo­imi prze­my­śle­nia­mi na temat archi­tek­tu­ry sys­te­mów, ich pro­jek­to­wa­nia i tym co z tego wynika. 

Bardzo cie­ka­wie pisze o tym, czym jest zło­żo­ność opro­gra­mo­wa­nia, o tym, że zło­żo­ność sys­te­mu to sto­pień kom­pli­ka­cji mode­lu dzie­dzi­no­we­go a nie całe­go sys­te­mu”. Typowy sys­tem (tu apli­ka­cja dla biz­ne­su) skła­da się w ponad 90% z biblio­tek, z któ­rych nie­wąt­pli­wie trze­ba umieć zbu­do­wać śro­do­wi­sko apli­ka­cji, jed­nak to nie one decy­du­ją o tym do cze­go słu­ży ten sys­tem i czy w ogó­le komu­kol­wiek do cze­goś słu­ży… Z biblio­tek, na któ­re nie mamy wpły­wu, ale musi­my (chce­my) ich użyć. 

Jaki to jest skom­pli­ko­wa­ny sys­tem? Ile ma klas/komponentów by uznać go za zło­żo­ny? Gdzie jest gra­ni­ca zło­żo­no­ści małej i dużej? Czym jest archi­tek­tu­ra i po co ona nam? O tym tu przeczytacie.

Polecam tę książ­kę każ­de­mu, kto ma ambi­cję pro­jek­to­wać archi­tek­tu­rę sys­te­mów biz­ne­so­wych. Uczy poko­ry. Zwracam tu uwa­gę, że oso­ba mówią­ca o sobie ana­li­tyk biz­ne­so­wy”, któ­re­go pro­duk­tem pra­cy mają być wyma­ga­nia na opro­gra­mo­wa­nie”, to nie zbie­racz nota­tek a pro­jek­tant . Albo niech zmie­ni zawód.. 

Yourdon, E., & Bloch, J. (2007). Marsz ku klę­sce: porad­nik dla pro­jek­tan­ta sys­te­mów. Wydawnictwa Naukowo-Techniczne. https://​lubi​my​czy​tac​.pl/​k​s​i​a​z​k​a​/​1​5​9​1​8​0​/​m​a​r​s​z​-​k​u​-​k​l​e​sce
Ozkaya, I. (2020). Building Blocks of Software Design. IEEE Software, 37(2), 3 – 5. https://​doi​.org/​1​0​.​1​1​0​9​/​M​S​.​2​0​1​9​.​2​9​5​9​049

Ochrona programów komputerowych w prawie własności intelektualnej

Wstęp

Na stro­nie PARP od pew­ne­go cza­su jest dostęp­ny tekst pod powyż­szym tytu­łem: Ochrona pro­gra­mów kom­pu­te­ro­wych w pra­wie wła­sno­ści inte­lek­tu­al­nej . Autor zaczy­na od słów:

Wraz ze wzro­stem zna­cze­nia pro­gra­mów kom­pu­te­ro­wych w obro­cie gospo­dar­czym, rośnie tak­że potrze­ba ich nale­ży­tej ochro­ny przed naru­sze­nia­mi. Jej obec­ny kształt w pol­skim pra­wie jest rezul­ta­tem dłu­go­let­nich prac, zarów­no na szcze­blu mię­dzy­na­ro­do­wym, jak i krajowym. 

Opracowanie jest god­ne uwa­gi gdyż rze­czo­wo opi­su­je stan praw­ny ryn­ku opro­gra­mo­wa­nia w obsza­rze war­to­ści inte­lek­tu­al­nych. Z uwa­gi na to, że autor doko­nał ana­li­zy z per­spek­ty­wy praw­nej, posta­no­wi­łem na przy­kła­dach prak­tycz­nych poka­zać przy­czy­ny i skut­ki opi­sy­wa­nych praw­nych aspek­tów inży­nie­rii oprogramowania. 

Omówienie

Cytat (wszyst­kie nie­ozna­czo­ne cyta­ty pocho­dzą z powyż­sze­go opracowania):

W toku dys­ku­sji nad wybo­rem ade­kwat­ne­go reżi­mu praw­ne­go dla ochro­ny opro­gra­mo­wa­nia, roz­wa­ża­no trzy roz­wią­za­nia: – ochro­na na grun­cie pra­wa autor­skie­go tj. trak­to­wa­nie pro­gra­mów jako utwo­rów, – ochro­na na pod­sta­wie pra­wa wła­sno­ści prze­my­sło­wej tj. paten­to­wa­nie pro­gra­mów jako wyna­laz­ków, – stwo­rze­nie spe­cjal­ne­go, odręb­ne­go sys­te­mu ochro­ny. Mimo, że intu­icja może pod­po­wia­dać słusz­ność dru­gie­go ze wska­za­nych roz­wią­zań – pro­gram kom­pu­te­ro­wy koja­rzy­my jako roz­wią­za­nie o cha­rak­te­rze tech­nicz­nym i bar­dziej użyt­ko­wym, niż arty­stycz­nym – to w porząd­ku euro­pej­skim jako pod­sta­wo­wy przy­ję­to model ochro­ny prawnoautorskiej.

I wła­śnie intu­icji bym w to mie­szał. Generalnie w każ­dej inży­nie­rii, opro­gra­mo­wa­nia tak­że, utrwa­le­nie okre­ślo­nej kon­struk­cji może zostać wyra­żo­ne w posta­ci: opi­su w for­mie doku­men­ta­cji tech­nicz­nej, spe­cy­fi­ka­cji tech­no­lo­gii wytwa­rza­nia (tak zwa­na recep­tu­ra, to też doku­men­ta­cja) oraz zma­te­ria­li­zo­wa­ne­go osta­tecz­ne­go pro­duk­tu. Są to kolej­no: rysun­ki tech­nicz­ne Projektu Technicznego, pro­ce­du­ry opi­su­ją­ce wytwo­rze­nie: mate­ria­ły, narzę­dzia i czyn­no­ści, oraz pro­dukt, któ­ry osta­tecz­nie powstał. Pierwsze dwa to: doku­men­ty i ich treść chro­nio­ne jest pra­wem autor­skim, bo są to utwo­ry (rysun­ki, sche­ma­ty, opi­sy, wyka­za­nie ich uni­kal­no­ści moim zda­niem nie jest trudne). 

Trzeci to pra­ca wytwór­cza pod dyk­tan­do” (wyko­na­nie imple­men­ta­cji) i mie­ści wyłącz­nie w kate­go­riach sta­ran­ne­go dzia­ła­nia” . Projekt Techniczny jest utwo­rem pier­wot­nym, opra­co­wa­na tech­no­lo­gia wytwa­rza­nia jest utwo­rem zależ­nym, osta­tecz­ny pro­dukt jest rze­mio­słem .

To co wyróż­nia inży­nie­rię opro­gra­mo­wa­nia, to abs­trak­cyj­ność pro­duk­tu koń­co­we­go. Z per­spek­ty­wy filo­zo­fii opro­gra­mo­wa­nia, kom­pu­ter to uni­wer­sal­ny mecha­nizm, kom­pu­ter zaś defi­niu­je­my jako pro­ce­sor, pamięć i pro­gram. Więc ten ostat­ni – opro­gra­mo­wa­nie – z zasa­dy nie jest samo­dziel­nym bytem . Produktem koń­co­wym z zasa­dy jest zawsze dzia­ła­ją­cy kom­pu­ter. Dlatego okre­śle­nie, że pro­gram to:

…zestaw roz­ka­zów lub instruk­cji prze­zna­czo­nych do uży­cia bez­po­śred­nio lub pośred­nio w kom­pu­te­rze w celu osią­gnię­cia okre­ślo­ne­go rezul­ta­tu. Określenia pro­gra­mu kom­pu­te­ro­we­go prze­wi­dzia­ne w usta­wo­daw­stwach innych kra­jów nie odbie­ga­ją zasad­ni­czo od defi­ni­cji wyżej cyto­wa­nej, sku­pia­jąc się na trzech ww. ele­men­tach, czy­li 1) zesta­wie instruk­cji, 2) adre­so­wa­nych do kom­pu­te­ra, 3) któ­rych wyko­na­nie pro­wa­dzi do okre­ślo­nych rezultatów.

wyda­je się jak naj­bar­dziej ade­kwat­ne. Uważam, że utwo­rem z zasa­dy jest każ­dy pro­jekt np. wyra­żo­ny jako rysun­ki tech­nicz­ne (tak jak w budow­nic­twie czy bran­ży lotniczej). 

Czy pro­gram jest wła­sno­ścią prze­my­sło­wą? W Polsce nie moż­na paten­to­wać opro­gra­mo­wa­nia jako takie­go, ale opro­gra­mo­wa­nie będą­ce inte­gral­ną czę­ścią urzą­dze­nia owszem (np. pro­gram ste­ru­ją­cy wtry­skiem sil­ni­ka ben­zy­no­we­go czy kom­pu­te­ro­wy ste­row­nik pral­ki, patrz: mecha­tro­ni­ka). Jednak pro­gram czę­sto nie­sie tak­że know-how (np. opis wspo­mnia­ne­go mechanizmu). 

Popatrzmy na map­kę poniżej:

(źr. https://​open​ca​ching​.pl/​v​i​e​w​c​a​c​h​e​.​p​h​p​?​w​p​=​O​P​8​M3L)

Ta mapa, jako gra­fi­ka, jest chro­nio­na pra­wem autor­skim. Jednak jej treść to know-how pira­ta, któ­ry scho­wał skarb i udo­ku­men­to­wał jak do nie­go dotrzeć: to jest chro­nio­ne know-how. To zna­czy, że powyż­sza mapa to utwór chro­nio­ny pra­wem autor­skim, jej treść (infor­ma­cja jaką nie­sie) to tajem­ni­ca przed­się­bior­stwa, chro­nio­na jako know-how. 

Identycznie to wyglą­da, gdy mamy do czy­nie­nia z rysun­ka­mi tech­nicz­ny­mi czy nawet gra­ficz­ny­mi pro­jek­ta­mi np. buci­ków (pro­du­cen­ci butów, mają pre­cy­zyj­ny pro­jekt każ­de­go nowe­go mode­lu butów: rysun­ki – pro­jek­ty gra­ficz­ne, któ­re coraz czę­ściej natych­miast reje­stru­ją u nota­riu­szy, to chro­ni ich przed nie­uczci­wym kon­ku­ren­tem, któ­ry chciał­by bez zgo­dy pro­du­ko­wać iden­tycz­nie wyglą­da­ją­ce buty, treść i poświad­czo­na nota­rial­nie data powsta­nia takiej doku­men­ta­cji jest dowo­dem na to kto był pierw­szy”, a szcze­gó­ło­wość i uni­kal­ność pro­jek­tu czy­ni go utworem).

Tak więc owszem: pro­duk­ty inży­nie­rii, inży­nie­rii opro­gra­mo­wa­nia tak­że, chro­ni pra­wo autor­skie bo treść (postać) doku­men­ta­cji tech­nicz­nej jest uni­kal­nym utwo­rem. A kod pro­gra­mu? Jeżeli kod jest pierw­szym utrwa­le­niem okre­ślo­nej wie­dzy (tre­ści, opi­su mecha­ni­zmu dzia­ła­nia) to tak. Jeżeli jed­nak sta­no­wi reali­za­cję (imple­men­ta­cję) pro­jek­tu logi­ki wyra­żo­ne­go w posta­ci algo­ryt­mów, wzo­rów mate­ma­tycz­nych i sfor­ma­li­zo­wa­nych sche­ma­tów blo­ko­wych, to jako tekst kodu źró­dło­we­go, sta­no­wić może utwór zależ­ny (o ile pro­gra­mi­sta miał jakąś swo­bo­dę w tej pra­cy), a naj­czę­ściej jedy­nie pro­dukt sta­ran­ne­go dzia­ła­nia, nie­chro­nio­ny już pra­wem autor­skim (dla­te­go czę­sto mówi­my nie pro­gra­mi­sta a koder). 

Dlatego autor słusz­nie zwra­ca uwa­gę na fakt, że 

…nie będzie­my mogli dane­go pro­gra­mu kom­pu­te­ro­we­go uznać za utwór, jeśli został on w peł­ni zde­ter­mi­no­wa­ny przez czyn­ni­ki zewnętrz­ne, takie jak np. zamie­rzo­ny cel opro­gra­mo­wa­nia. Innymi sło­wy, aby móc mówić o speł­nie­niu prze­słan­ki indy­wi­du­al­no­ści”, pro­gra­mi­sta musi dys­po­no­wać odpo­wied­nim stop­niem swo­bo­dy twórczej.

To dla­te­go, pro­gram wytwo­rzo­ny na pod­sta­wie wcze­śniej opra­co­wa­ne­go pro­jek­tu (zde­ter­mi­no­wa­ny), mają­ce­go cha­rak­ter utwo­ru, nie jest samo­dziel­nym utwo­rem. Biorąc pod uwa­gę fakt, że opro­gra­mo­wa­nie reali­zu­je (może), nie raz, zło­żo­ny mecha­nizm dzia­ła­nia czy prze­twa­rza­nia danych, może tak­że sta­no­wić – jako ele­ment kom­pu­te­ra – przed­miot pra­wa wła­sno­ści przemysłowej. 

W kwe­stii dodat­ko­wych regu­la­cji. Moim zda­niem nie ma żad­ne­go powo­du by sys­te­my infor­ma­tycz­ne mia­ły jaki­kol­wiek dedy­ko­wa­ny roz­dział w pra­wie, jest to inży­nie­ria jak każ­da inna. Nie przy­pad­kiem w orze­cze­niach i uza­sad­nie­niach prze­wi­ja­ją się np. ana­lo­gie do pra­wa budow­la­ne­go (pro­jekt, wyko­na­nie, nad­zór autorski). 

Autor pisze:

Gwoli ści­sło­ści trze­ba wyja­śnić, że w ani w usta­wie, ani w orzecz­nic­twie nie usta­lo­no w spo­sób pre­cy­zyj­ny i jed­no­znacz­ny gene­ral­ne­go mini­mal­ne­go pozio­mu indy­wi­du­al­no­ści, któ­ry musi repre­zen­to­wać dany wytwór inte­lek­tu­al­ny, żeby mógł zostać uzna­ny za utwór w rozu­mie­niu pra­wa autorskiego.

Owszem nie ma ści­słe­go kry­te­rium, jed­nak oce­na na ile dru­gi podob­ny” utwór przy­pad­kiem” jest podob­ny do pierw­sze­go, jest dość łatwa. Kilka linii tek­stu lub jeden bar­dzo ogól­ny i nie­for­mal­ny sche­mat blo­ko­wy może budzić wąt­pli­wo­ści (pra­wo nie chro­ni idei), jed­nak jeże­li jest to opis mecha­ni­zmu, to nawet pro­sty szkic może mieć walo­ry uni­kal­no­ści. Poniższe np. trud­no nazwać tyl­ko ideą czy przy­pad­ko­wym rysunkiem:

PODSTAWY CYBERNETYKI REGULACJA PROCESÓW FIZJOLOGICZNYCH - ppt video online  pobierz
Regulator Watt’a, doku­men­ta­cja (sche­mat blo­ko­wy) paten­tu w USA (źr.: Prawo autor­skie w pro­jek­tach IT).

W zasa­dzie iden­tycz­ny mecha­nizm może reali­zo­wać kom­pu­ter wypo­sa­żo­ny w odpo­wied­nie opro­gra­mo­wa­nie, któ­re moż­na zapro­jek­to­wać (ści­śle udo­ku­men­to­wać) nie wska­zu­jąc nawet kon­kret­ne­go języ­ka pro­gra­mo­wa­nia (nazy­wa się to Platform Independent Model, patrz MDA). Nie trud­no też wyka­zać uni­kal­ność powyż­sze­go szki­cu i nie jest trud­nym wyka­za­nie, że to war­tość przemysłowa. 

Bardzo waż­nym ele­men­tem sta­nu praw­ne­go jest to, że idee nie są chro­nio­ne. Innymi sło­wy wyma­ga­nia wyra­żo­ne spi­sem potrzeb: lista wyma­gań funk­cjo­nal­nych i poza-funk­cjo­nal­nych, user sto­ry itp. for­my, nie są chro­nio­ne. Generalnie odkry­cia nauko­we tak­że nie są chro­nio­ne bo to co odkry­to nie jest dzie­łem czło­wie­ka. W nauce dzie­łem czło­wie­ka czło­wie­ka jest zro­zu­mie­nie i udo­ku­men­to­wa­nie mecha­ni­zmu okre­ślo­ne­go zja­wi­ska (efek­tów doko­ny­wa­nych obser­wa­cji). Jednak spe­cy­fi­ka­cje mecha­ni­zmu dzia­ła­nia cze­goś, będą­ce­go wyna­laz­kiem a nie odkry­ciem, są chro­nio­ne. Dla jasno­ści; nauka opi­su­je to co już ist­nie­je, inży­nie­ra two­rzy nowe:

Wiele emo­cji budzą pra­wa mająt­ko­we do opro­gra­mo­wa­nia. Moim zda­niem jest to nie­zro­zu­mie­nie tego, że treść pro­gra­mu kom­pu­te­ro­we­go rozu­mia­na jako utwór lite­rac­ki może być przed­mio­tem roz­wa­żań o uni­kal­no­ści tek­stu, jed­nak isto­tą pro­gra­mu kom­pu­te­ro­we­go jest to, że jako zestaw instruk­cji dla pro­ce­so­ra nie jest nigdy samo­dziel­nym bytem: ma war­tość jedy­nie jako część kom­pu­te­ra (uru­cho­mie­nie go z pomo­cą pro­ce­so­ra i pamię­ci). W zasa­dzie sko­pio­wa­nie tre­ści pro­gra­mu stwa­rza zagro­że­nie tyl­ko gdy pla­no­wa­ne jest wyko­na­nie go w kom­pu­te­rze lub odczy­ta­nie i sko­pio­wa­nie zaim­ple­men­to­wa­ne­go w nim mecha­ni­zmu, mogą­ce­go sta­no­wić war­tość inte­lek­tu­al­na (know-how, rewers-inżynieria). 

Owszem, nie trze­ba rozu­mieć” kodu i zaim­ple­men­to­wa­ne­go w nim mecha­ni­zmu, by odnieść korzy­ści mająt­ko­we z uży­cia go jako dzia­ła­ją­ce­go pro­gra­mu (zna­ko­mi­ta więk­szość opro­gra­mo­wa­nia użyt­ko­we­go), jed­nak gene­ral­nie chro­ni­my mecha­nizm, a pra­wa mająt­ko­we do pro­gra­mu to pra­wa dys­po­no­wa­nia nim (mecha­ni­zmem), bez wzglę­du na for­mę wyra­że­nia: użyt­kow­nik kal­ku­la­to­ra korzy­sta z opro­gra­mo­wa­nia imple­men­tu­ją­ce­go okre­ślo­ne algo­ryt­my, reali­zu­jąc zło­żo­ne ope­ra­cje mate­ma­tycz­ne. Odnosi korzy­ści mimo tego, że nie zna i nie rozu­mie kodu pro­gra­mu wyko­ny­wa­ne­go w tym kal­ku­la­to­rze (któ­ry jest komputerem). 

Autorstwo. Kto jest twór­cą pro­gra­mu kom­pu­te­ro­we­go? Ten kto pierw­szy go zapro­jek­to­wał i utrwa­lił, bez wzglę­du na for­mę wyra­zu (instruk­cje i algo­ryt­my prze­twa­rza­nia danych, wyra­żo­ne jako sche­ma­ty blo­ko­we to też pro­gram). Tak więc pro­gra­mi­sta, któ­ry napi­sze kod w okre­ślo­nym języ­ku pro­gra­mo­wa­nia (Java, C++, .Net, PHP, itp.), na pod­sta­wie pro­jek­tu, nie jest jego twór­cą, podob­nie jak nie jest twór­cą eki­pa budow­la­na budu­ją­ca na pod­sta­wie pro­jek­tu architektonicznego.

Autor i autor­skie pra­wa oso­bi­ste. Autor utwo­ru (oso­ba) jest okre­ślo­ny, autor utwo­ru (jego dane) jest jego – utwo­ru – atry­bu­tem nie­pod­le­ga­ją­cym zmia­nie. Pana Tadeusza napi­sał Adam Mickiewicz, i nic tego nie zmie­ni, jed­nak korzy­ści mająt­ko­we może czer­pać każ­dy inny, komu prze­ka­za­ne zosta­ną pra­wa mająt­ko­we do tego utwo­ru (pierw­szym zby­wa­ją­cym musi być jed­nak autor). 

Autorskie pra­wa oso­bi­ste są bar­dzo waż­ne, ich celem jest gene­ral­nie ochro­na dobre­go imie­nia auto­ra. Co do zasa­dy mamy waż­ne poję­cie inte­gral­no­ści utwo­ru: nie wol­no inge­ro­wać w jego treść bo fir­mu­je ją swo­im imie­niem autor. Za zgo­dą auto­ra mogą powsta­wać utwo­ry zależ­ne, jed­nak nie wol­no zmie­nić tre­ści utwo­ru pier­wot­ne­go, wol­no go cyto­wać, two­rzyć adap­ta­cje, jed­nak tak­że za zgo­dą auto­ra. Zmiana tre­ści utwo­ru, tu jest to zmia­na pro­jek­tu (podob­nie jak w pra­wie budow­la­nym) jest moż­li­wa wyłącz­nie ręka­mi auto­ra”, któ­ry jako jedy­ny zna inten­cję tego co stwo­rzył i pono­si odpo­wie­dzial­ność za skut­ki. Co cie­ka­we pra­wo autor­skie wyłą­cza ten kon­kret­ny zakaz dla kod pro­gra­mu, co tak­że wska­zu­je na to, że osta­tecz­ny pro­dukt: kod, jest raczej rze­mio­słem niż dziełem. 

Autor w zakoń­cze­niu pisze:

Jednak jak to zwy­kle bywa, to, co jed­ni uwa­ża­ją za zale­ty, inni trak­tu­ją jako sła­bo­ści. I tak wła­śnie pośród prze­ciw­ni­ków sys­te­mu praw­no­au­tor­skie­go prze­wa­ża­ją argu­men­ty kry­ty­ku­ją­ce nad­mier­ny libe­ra­lizm w uzy­ski­wa­niu ochro­ny praw­no­au­tor­skiej – tzn. ochro­na przy­zna­wa­na jest rów­nież roz­wią­za­niom wtór­nym z punk­tu widze­nia uży­tecz­no­ści i funk­cjo­nal­no­ści. Prawo autor­skie chro­ni bowiem jedy­nie for­mę wyra­że­nia, a nie pomysł czy wła­śnie okre­ślo­ne funk­cjo­nal­no­ści. Poza tym kry­ty­ka doty­czy rów­nież zbyt dłu­gie­go okre­su ochro­ny autor­skich praw majątkowych.

Z tym aku­rat trud­no mi się zgo­dzić bo: 

  • nie rozu­miem pro­ble­mu roz­wią­zań wtór­nych, bo albo coś jest nie­za­leż­nym odręb­nym utwo­rem albo jest jakąś for­mą utwo­ru zależnego,
  • pra­wo autor­skie chro­ni for­mę wyra­że­nia, ale ta z zasa­dy nie­sie okre­ślo­ną treść, dla­te­go gene­ral­nie isto­tą jest treść, a nie for­ma wyra­że­nia, ta jest wtór­na. Innymi sło­wy nie ma zna­cze­nia czy dany mecha­nizm jest bar­dzo pre­cy­zyj­nie opi­sa­ny tek­stem i wzo­ra­mi mate­ma­tycz­ny­mi, czy pre­cy­zyj­nym sche­ma­tem blo­ko­wym, w ww. przy­kła­dzie chro­nio­ny jest mecha­nizm regu­la­to­ra Watt’a, bez wzglę­du na to czy został wyra­żo­ny takim czyn­nym sche­ma­tem lub opisem. 

W moim oso­bi­stym odczu­ciu, szko­dli­we jest wydzie­le­nie i oddzie­le­nie praw mająt­ko­wych od auto­ra. Ochrona auto­ra to moim zda­niem, przede wszyst­kim jego dobre imię. Prawa do czer­pa­nia bier­nych przy­cho­dów z praw mająt­ko­wych nisz­czą eko­no­mię, powo­du­ją tak­że, że auto­rzy są wyko­rzy­sty­wa­ni (np. pra­wo pra­cy z zasa­dy prze­no­si pra­wa mająt­ko­we do pro­duk­tów pra­cy z auto­ra na jego pra­co­daw­cę). Osoba two­rzą­ca, mają­ca takie zdol­no­ści i umie­jęt­no­ści, powin­na być wyna­gra­dza­na raz za pra­cę jaką wyko­na­ła, pra­wo autor­skie powin­no gwa­ran­to­wać brak moż­li­wo­ści pod­szy­wa­nia się pod cudze dzie­ła oraz chro­nić przed powtór­nym sprze­da­niem” tego same­go, ale cudze­go, efek­tu pra­cy (pla­giat). Na świe­cie od lat toczą się dys­ku­sje na ten temat. 

W przy­pad­ku opro­gra­mo­wa­nia, chro­nio­ne są cechy reali­zu­ją­ce mecha­nizm, np. mecha­nizm nali­cza­nia upu­stu na fak­tu­rze. Pojawiają się czę­sto spo­ry o to czy pro­gram słu­żą­cy do wysta­wia­nia fak­tur (ich treść jest regu­lo­wa­na pra­wem) może być chro­nio­ny pra­wem autor­skim. Otóż owszem, bo fak­tu­ra, jako efekt koń­co­wy dzia­ła­nia pro­gra­mu, może być stwo­rzo­na wie­lo­ma róż­ny­mi mecha­ni­zma­mi, dają­cy­mi jako efekt (pro­dukt) tę samą, zgod­ną z pra­wem fak­tu­rę. Więc wzór na wyli­cze­nie podat­ku VAT nie może być przed­mio­tem ochro­ny, jed­nak wzór na upust wg. pro­gra­mu lojal­no­ścio­we­go, owszem. Do tego spo­sób (meto­da) wytwo­rze­nie tre­ści doku­men­tu (archi­tek­tu­ra opro­gra­mo­wa­nia, uży­te algo­ryt­my i meto­dy) jakim jest fak­tu­ra, nie jest zde­ter­mi­no­wa­ny jego osta­tecz­ną posta­cią (tre­ścią, efek­tem), więc mamy tu pole do indy­wi­du­al­nej twór­czo­ści” auto­ra. W ten spo­sób są np. chro­nio­ne róż­ne tech­no­lo­gie wytwa­rza­nia takie­go same­go pro­duk­tu (sub­stan­cji, itp.). 

Podsumowanie

Własność inte­lek­tu­al­na to efek­ty twór­czej dzia­łal­no­ści ludz­kie­go inte­lek­tu, posia­da­ją­ce cha­rak­ter nie­ma­te­rial­ny, ucie­le­śnio­ne w mate­rial­nej posta­ci. Innymi sło­wy jest to to wszyst­ko, co uni­kal­ne­go i ory­gi­nal­ne­go jest w sta­nie wymy­ślić czło­wiek. Własność inte­lek­tu­al­na jest obec­na we wszyst­kich sfe­rach życia, w edu­ka­cji, roz­ryw­ce i oczy­wi­ście w biz­ne­sie, bez wzglę­du na wiel­kość i zasięg dzia­ła­nia fir­my. W kre­atyw­nych i inno­wa­cyj­nych bran­żach wła­sność inte­lek­tu­al­na czę­sto ma fun­da­men­tal­ne zna­cze­nie, ale jest rów­nie potrzeb­na pod­mio­tom z bar­dziej tra­dy­cyj­nych sek­to­rów. Prawa wła­sno­ści inte­lek­tu­al­nej dzie­li­my na dwie pod­sta­wo­we kate­go­rie:
- pra­wa wła­sno­ści prze­my­sło­wej obej­mu­ją­ce paten­ty na wyna­laz­ki, wzo­ry użyt­ko­we, wzo­ry prze­my­sło­we, zna­ki towa­ro­we, ozna­cze­nia geo­gra­ficz­ne i topo­gra­fie ukła­dów sca­lo­nych;
- pra­wa autor­skie i pra­wa pokrewne. 

Tak więc moż­na stwier­dzić, że:

  • Prawo autor­skie chro­ni utwo­ry, czy­li wszel­kie tre­ści o uni­kal­nym cha­rak­te­rze . Są to więc tak­że wszel­kie­go rodza­ju rysun­ki tech­nicz­ne, sche­ma­ty blo­ko­we, wyra­żo­ne mate­ma­tycz­nie lub gra­ficz­nie algo­ryt­my wraz tek­sta­mi komen­ta­rzy do nich.
  • Własność prze­my­sło­wą, czy­li sze­ro­ko poję­te kon­struk­cje inży­nier­skie, chro­ni Prawo Patentowe, w przy­pad­ku opro­gra­mo­wa­nia nie ma bez­po­śred­nie­go zasto­so­wa­nia, o ile opro­gra­mo­wa­nie to nie jest czę­ścią paten­to­wa­ne­go urządzenia.
  • Treść utwo­ru może nieść infor­ma­cję sta­no­wią­cą tajem­ni­cę przed­się­bior­stwa, zwa­ną tak­że know-how . Informacją tą może być opis wewnętrz­nej kon­struk­cji urzą­dze­nia lub tyl­ko mecha­ni­zmu jego dzia­ła­nia, doty­czy to tak­że archi­tek­tu­ry i mecha­ni­zmu dzia­ła­nia opro­gra­mo­wa­nia (jego pro­jekt techniczny).
  • Oprogramowanie powsta­ją­ce na pod­sta­wie pro­jek­tu tech­nicz­ne­go ma sta­tus utwo­ru zależ­ne­go, nie może więc powstać bez zgo­dy auto­ra pier­wot­ne­go Projektu (wyma­ga­ne pra­wa do two­rze­nia utwo­rów zależ­nych). Wykonawca opro­gra­mo­wa­nia nie ma pra­wa do dys­po­no­wa­nia nim bez zgo­dy auto­ra Projektu.
  • Dostosowanie opro­gra­mo­wa­nia (np. zmia­na lub roz­sze­rze­nie funk­cjo­nal­no­ści), z per­spek­ty­wy praw autor­skich, wyma­ga pod­ję­cia decy­zji o meto­dzie dosto­so­wa­nia i zabez­pie­cze­nia praw autor­skich do tych zmian (patrz arty­kuł: Kastomizacja opro­gra­mo­wa­nia).

Wyczerpujący opis kwe­stii ochro­ny praw autor­skich i know-how w bran­ży infor­ma­tycz­nej zawie­ra moje opra­co­wa­nie na stro­nie: Ochrona war­to­ści inte­lek­tu­al­nych i know-how w orga­ni­za­cji.

Zakończę ten wpis cyta­tem z pew­nej publi­ka­cji nauko­wej z 2019 roku:

Programming is not sole­ly abo­ut con­struc­ting softwa­re — pro­gram­ming is abo­ut desi­gning software.

Źródła

Dorota Rzążewska, Tomasz Gawliczek, Anna Kupińska-Szczygielska, & Karolina Tołwińska. (2021). Własność inte­lek­tu­al­na dla przed­się­bior­cy. Urząd Patentowy Rzeczypospolitej Polskiej. https://​uprp​.gov​.pl/​s​i​t​e​s​/​d​e​f​a​u​l​t​/​f​i​l​e​s​/​2​021 – 08/W%C5%82asno%C5%9B%C4%87%20intelektualna%20dla%20przedsi%C4%99biorcy%20-%20broszura.pdf
Jezierski, J. (2019, czerw­ca). Ochrona pro­gra­mów kom­pu­te­ro­wych w pra­wie wła­sno­ści inte­lek­tu­al­nej – część I – PARP – Centrum Rozwoju MŚP. PARP. https://www.parp.gov.pl/component/content/article/57199:ochrona-programow-komputerowych-w-prawie-wlasnosci-intelektualnej-czesc‑i
OMG​.org. (2014, June 18). Model Driven Architecture (MDA). https://​www​.omg​.org/​m​da/
Wolak, G. J. (2019). Umowa o dzie­ło jako zobo­wią­za­nie rezul­ta­tu. https://​doi​.org/​1​0​.​3​4​6​9​7​/​2​451 – 0807-SP-2019 – 1‑006
Craver, C., & Tabery, J. (2019). Mechanisms in Science. In E. N. Zalta (Ed.), The Stanford Encyclopedia of Philosophy (Summer 2019). Metaphysics Research Lab, Stanford University. https://​pla​to​.stan​ford​.edu/​e​n​t​r​i​e​s​/​s​c​i​e​n​c​e​-​m​e​c​h​a​n​i​s​ms/
Murawski, R. (Ed.). (2015). Filozofia mate­ma­ty­ki i infor­ma­ty­ki. Copernicus Center Press.
Ozkaya, I. (2020). Building Blocks of Software Design. IEEE Software, 37(2), 3 – 5. https://​doi​.org/​1​0​.​1​1​0​9​/​M​S​.​2​0​1​9​.​2​9​5​9​049

Dlaczego nie używam poczty elektronicznej do komunikacji w projektach

Wstęp

Od lat spo­ty­kam się w lite­ra­tu­rze z zakre­su zarzą­dza­nia, z kry­ty­ką pocz­ty elek­tro­nicz­nej jako narzę­dziem zarzą­dza­nia czym­kol­wiek (patrz: Sabotaż…2013). Poczta elek­tro­nicz­na (podob­nie jak pakie­ty biu­ro­we w ogó­le) jest typo­wym przy­kła­dem mak­sy­my: uła­twie­nie nie zawsze jest ulep­sze­niem. W klien­cie pocz­ty elek­tro­nicz­nej zarów­no treść jak i spo­sób adre­so­wa­nia (co i do kogo, kopia, itp.) nie pod­le­ga żad­nej stan­da­ry­za­cji ani restryk­cji (pocz­ta elek­tro­nicz­na czę­sto słu­ży do wypro­wa­dza­nia danych z fir­my). Jak dodać do tego fakt, że załącz­ni­ki są nie­wi­docz­ne w narzę­dziach do lokal­ne­go wyszu­ki­wa­nia, że mamy na ser­we­rach fil­try anty­spa­mo­we któ­rych regu­ły nie pod­da­ją się kon­tro­li użyt­kow­ni­ków, że nie panu­je­my nad tym co inni mają w swo­ich skrzyn­kach pocz­to­wych, to mamy obraz abso­lut­ne­go bra­ku pano­wa­nia nad infor­ma­cją w orga­ni­za­cji i chaosu. 

Swego cza­su dr Paweł Litwiński, praw­nik, napi­sał kry­tycz­ny arty­kuł o zasto­so­wa­niu pocz­ty elek­tro­nicz­nej przez adwo­ka­tów. Jego tekst był sze­ro­ko cyto­wa­ny przez wie­lu auto­rów, tu jeden z takich arty­ku­łów. Wybrałem kil­ka waż­nych kwestii:

Praktyka poka­zu­je, że wie­lu adwo­ka­tów i rad­ców praw­nych korzy­sta z dar­mo­wych skrzy­nek, tak­że tych wprost zastrze­ga­ją­cych sobie pra­wo do ska­no­wa­nia korespondencji. […]

Konflikt pomię­dzy obo­wiąz­kiem ochro­ny infor­ma­cji a warun­ka­mi narzu­co­ny­mi w regu­la­mi­nach dar­mo­wych usług to jed­no. Czym innym są kwe­stie bezpieczeństwa.[…]

? Na logi­kę, lepiej żeby o mate­ria­łach obję­tych tajem­ni­cą adwo­kac­ką nie dowie­dział się żaden dostaw­ca, ale z dru­giej stro­ny, rzad­ko któ­rej kan­ce­la­rii praw­nej uda się samo­dziel­nie skon­fi­gu­ro­wać ser­wer pocz­to­wy tak, aby był rów­nie bez­piecz­ny i nie­awa­ryj­ny, jak infra­struk­tu­ra np. Gmaila. Oczywiście, moż­na zle­cić to zewnętrz­nej pol­skiej fir­mie, ale wte­dy mamy ten sam pro­blem z zaufa­niem, co w przy­pad­ku korzy­sta­nia z ser­we­rów np. Google ? zwra­ca uwa­gę Piotr Konieczny, eks­pert ds. cyber­bez­pie­czeń­stwa z ser­wi­su Niebezpiecznik​.pl. ? Abstrahując więc od aspek­tów praw­nych, roz­pa­tru­jąc pro­blem wyłącz­nie na płasz­czyź­nie bez­pie­czeń­stwa, tj. ochro­ny skrzyn­ki przed ata­ka­mi, moim zda­niem praw­ni­kom nie­dy­spo­nu­ją­cym budże­tem na bez­pie­czeń­stwo takim, jaki posia­da­ją pro­fe­sjo­nal­ni dostaw­cy usług pocz­to­wych, lepiej i pro­ściej było­by wyko­rzy­stać infra­struk­tu­rę np. Google?a ? doda­je. Jego zda­niem praw­ni­cy powin­ni przede wszyst­kim roz­wa­żyć moż­li­wość szy­fro­wa­nia kore­spon­den­cji. Wtedy zarów­no dar­mo­wy, jak i płat­ny dostaw­ca usług nie będzie w sta­nie jej podej­rzeć. Szyfrowanie jest bez wąt­pie­nia naj­bez­piecz­niej­szym spo­so­bem, ale wią­że się z koniecz­no­ścią dostar­cze­nia klu­cza czy hasła odbior­cy, a ten nie zawsze godzi się na takie nie­do­god­no­ści. Co wię­cej, klien­ci kan­ce­la­rii sami czę­sto korzy­sta­ją z dar­mo­wych skrzy­nek. ? I nie rozu­mie­ją, dla­cze­go pouf­ne infor­ma­cje nie powin­ny być na nie prze­sy­ła­ne. Moim obo­wiąz­kiem jest wów­czas poin­for­mo­wać takie­go klien­ta o zagro­że­niach z tym zwią­za­nych. Oczywiście jeśli mimo tego będzie chciał uży­wać takiej skrzyn­ki do kore­spon­den­cji ze mną, to nie mogę mu tego zabro­nić ? zwra­ca uwa­gę dr Paweł Litwiński. ? Z dru­giej stro­ny są rów­nież klien­ci, któ­rzy wręcz wyma­ga­ją, by w kore­spon­den­cji z nimi uży­wać jedy­nie skrzy­nek zało­żo­nych na ich ser­we­rach. Tak restryk­cyj­ną mają poli­ty­kę bez­pie­czeń­stwa. Chcąc dla nich pra­co­wać, adwo­kat czy rad­ca musi przy­stać na te warun­ki ? doda­je ekspert.

(patrz: Darmowe e‑maile nie dla praw­ni­ków. Dostawca pocz­ty ska­nu­je jej zawar­tość – Forsal​.pl)

W 2013 roku pisałem:

W więk­szo­ści przy­pad­ków treść umiesz­cza­na jest w tre­ści ema­il??a lub w załącz­ni­ku (załą­czo­ne doku­men­ty). Jeżeli treść ema­ila nie jest szy­fro­wa­na (a gene­ral­nie nie jest, o ile sami o to nie zadba­my, co jed­nak, jak poka­zu­je cyto­wa­ny Niebezpiecznik, nie jest try­wial­ne) nasza kore­spon­den­cja, prze­cho­dząc przez publicz­ne łącza sie­ci Internet, jest jaw­na i łatwa do pod­słu­chi­wa­nia. Jak uczy­nić naszą kore­spon­den­cję (bar­dziej) niejawną?

(Patrz: Bezpieczny jak ema­il czy­li wca­le – Jarosław Żeliński IT-Consulting – Systemy Informacyjne)

Przypomnę klu­czo­we tezy powyż­sze­go arty­ku­łu. Generalnie waż­nych doku­men­tów nie nale­ży prze­sy­łać jako załącz­ni­ki z dwóch powo­dów: nie wie­my co sie z nimi dzie­je po dro­dze, nie wie­my czy zosta­ły dostar­czo­ne, i kie­dy, gdyż bar­dzo wie­lu użyt­kow­ni­ków ema­il ma wyłą­czo­ne auto­ma­tycz­ne ode­sła­nie potwier­dze­nia w swo­jej poczcie, co skut­ku­je tym, że po pro­stu jest to nie­wia­ry­god­na for­ma potwier­dza­nia. Poniżej sche­mat poka­zu­ją­cy dro­gę pocz­ty email: 

Droga pocz­ty elektronicznej.

Środkowa część (Internet) to tak­że poten­cjal­ne kolej­ne pośred­ni­czą­ce ser­we­ry, nie wie­my co sie na nich dzie­je. Tak więc dwie klu­czo­we wady ema­il to poten­cjal­ne ska­no­wa­nie tre­ści po dro­dze oraz brak kon­tro­li nad dorę­cze­niem. Czy moż­na ina­czej? Owszem: do prze­ka­zy­wa­nia doku­men­tów moż­na użyć repo­zy­to­rium (ser­we­ra pli­ków) z kon­tro­lo­wa­nym dostę­pem. Poniżej sche­mat blo­ko­wy archi­tek­tu­ry nie­ma­ją­cej ww. wad prze­sy­ła­nia doku­men­tów mailem:

Dokumenty prze­ka­zy­wa­ne za pośred­nic­twem repozytorium

Dokumenty w dro­dze” nie opusz­cza­ją repo­zy­to­rium: z nasze­go kom­pu­te­ra ładu­je­my je na ser­wer wska­zu­jąc ewen­tu­al­nie okre­ślo­ne­go adre­sa­ta (lub robi to mecha­nizm obsłu­gu­ją­cy wymia­nę tre­ści pomię­dzy uczest­ni­ka­mi), okre­ślo­na oso­ba dosta­je mailem infor­ma­cje, że jest dla niej doku­ment, żeby go pobrać musi się zalo­go­wać do repo­zy­to­rium. W efek­cie treść (plik) nie jest nigdzie nara­żo­na na ska­no­wa­nie, podej­rze­nie go itp. Tu ema­il słu­ży wyłącz­nie do moni­to­wa­nia fak­tu, że jest doku­ment do nas adre­so­wa­ny i że moż­na do pobrać, co zosta­nie odnotowane.

Mając nawet pro­ste, dostęp­ne przez inter­net, repo­zy­to­rium, moż­na umie­ścić tam dowol­ny plik i mailem poin­for­mo­wać adre­sa­ta (wcze­śniej zakła­da­my mu tam kon­to), że powi­nien pobrać plik. Serwer reje­stru­je zarów­no moment zała­do­wa­nia pli­ku jak i jego pobra­nia, co jest gwa­ran­to­wa­nym zna­kiem cza­su nada­nia i dorę­cze­nia. Minus takie­go roz­wią­za­nia to ręcz­na obsłu­ga całe­go pro­ce­su, plus to pano­wa­nie nad wszyst­kim i bezpieczeństwo.

Sprawdzonym, od daw­na, na ryn­ku pomy­słem jest sys­tem work­flow z udo­stęp­nia­nym repo­zy­to­rium, auto­ma­ty­zu­ją­cy cały ten proces: 

Architektura sys­te­mu wymia­ny danych z Repozytorium.

Uogólniając moż­na go przed­sta­wić jako ser­wer usług:

System work­flow ste­ro­wa­ny regułami

System dorę­czeń to tak napraw­dę funk­cjo­nal­ność apli­ka­cji typu work­flow zorien­to­wa­ne­go na zada­nia (task mana­ger), mają­cej moż­li­wość udo­stęp­nie­nia jej kon­tra­hen­tom. Funkcjonalność taką ma wie­le sys­te­mów CRM, sys­te­mów help­desk, wie­le repo­zy­to­riów pozwa­la na skon­fi­gu­ro­wa­nie sub­skryp­cji zda­rzeń powią­za­nych z doku­men­ta­mi. Zbudowanie takie­go sys­te­mu opar­te­go na regu­łach, zamiast na macier­zach praw dostę­pu do doku­men­tów, zna­ko­mi­cie uprasz­cza całość i dodat­ko­wo pod­no­si bez­pie­czeń­stwo (bar­dzo uła­twia wdra­ża­nie RODO) . Ciekawą funk­cjo­nal­no­ścią jest moż­li­wość blo­ko­wa­nia moż­li­wo­ści pobra­nia doku­men­tu na lokal­ny dysk, dozwo­lo­ne jest jedy­nie prze­glą­da­nie tre­ści w prze­wi­ja­nym oknie (ofe­ru­ją to nie­któ­re tego typu systemy).

Systemy tego typu są tak­że wdra­ża­ne jako zamien­nik pocz­ty elek­tro­nicz­nej wewnątrz orga­ni­za­cji. Tam gdzie pod­sta­wo­wym wewnętrz­nym sys­te­mem komu­ni­ka­cji jest pocz­ta elek­tro­nicz­na pro­ble­mem są giną­ce doku­men­ty oraz brak dostę­pu do doku­men­tów (skrzy­nek) osób nie­do­stęp­nych, będą­cych poza fir­mą (chro­ba, dele­ga­cja itp.). Generalnie pocz­ta jako skład doku­men­tów” ma tę pod­sta­wo­wą wadę, że doku­men­ty są roz­pro­szo­ne i zarza­dza­nie nimi w jed­no­li­ty spo­sób jest nie­moż­li­we. Stosowanie współ­dzie­lo­nych dys­ków nie roz­wią­zu­je cał­ko­wi­cie pro­ble­mu, bo po pierw­sze nie da się budo­wać reguł dostę­pu, po dru­gie wymia­na doku­men­tów z oso­ba­mi spo­za fir­my jest bar­dzo trud­na (np. wyma­ga uru­cho­me­nia VPN co jest trud­ne, wyma­ga inge­ren­cji w cudzy kom­pu­ter, i coraz czę­ściej nie jest to moż­li­we w wie­lu firmach).

Tak więc pocz­ta elek­tro­nicz­na, jako swo­bod­na komu­ni­ka­cja mię­dzy ludź­mi owszem, jest przy­dat­na. Jednak jako narzę­dzie do zarzą­dza­nia komu­ni­ka­cją, prze­pły­wem tre­ści, doku­men­tów ich wydań i dorę­czeń, jest bar­dzo zawod­na. A war­to wie­dzieć, że praw­na ochro­na know-how w UE, czy­li w Polsce tak­że, to przede wszyst­kim obo­wią­zek ochro­ny tre­ści przez pod­miot chro­nią­cy (udo­stęp­nia­ją­cy) takie dane. Dlatego dość kurio­zal­nie wyglą­da każ­da fir­ma, któ­ra wysy­ła­jąc mailem umo­wę o pouf­no­ści (NDA) wysy­ła potem tak­że mailem te pouf­ne” dokumenty…

Na zakończenie

Rozwiązań, reali­zu­ją­cych opi­sa­ne wyżej funk­cje, nie bra­ku­je. Główną blo­ka­dą ich wdra­ża­nia jest przy­zwy­cza­je­nie do swo­bo­dy. Jednak pocz­ta elek­tro­nicz­na jest kla­sycz­nym przy­kła­dem tego, że uła­twie­nie nie zawsze jest ulep­sze­niem. O wdra­ża­niu sys­te­mów work­flow, panu­ją­cych nad komu­ni­ka­cją i jej pouf­no­ścią, mówi się podob­nie jak o sys­te­mach kopii zapa­so­wych: fir­my dzie­lą się na te, któ­re wdro­ży­ły sku­tecz­ny work­flow i na te któ­re wdrożą.

Kilka przy­kła­dów (nie ofe­ru­ję tych sys­te­mów, to nie są reko­men­da­cje a przykłady):

  • Biuro księ­go­we, któ­re mnie obsłu­gu­je, ode­szło od pro­ste­go sys­te­mu FK i komu­ni­ka­cji mailo­wej (prze­ka­zy­wa­nie doku­men­tów kosz­to­wych, wysy­ła­nie klien­tom dekla­ra­cji podat­ko­wych, rapor­tów itp.), obec­nie korzy­sta z podat​ki​po​dat​ki​.pl.
  • Zaczynałem jak wie­lu od pocz­ty elek­tro­nicz­nej, po kil­ku przy­go­dach z doku­men­ta­mi w pro­jek­tach (kto, co, kie­dy i komu) szyb­ko wdro­ży­łem dar­mo­wy, potem sup­por­to­wa­ny osTicket (na począ­tek bar­dzo dobry i łatwy we wdrożeniu). 
  • Z uwa­gi na spe­cy­fi­kę mojej pra­cy (pra­ca pole­ga­ją­ca na zbie­ra­niu danych i two­rze­niu rapor­tów z ana­liz, ich recen­zo­wa­nie przez klien­tów) uży­wam obec­nie do komu­ni­ka­cji bar­dziej zaawan­so­wa­ne­go opro­gra­mo­wa­nia PostMania.
  • U wie­lu klien­tów spo­ty­kam, popu­lar­ny w ser­wi­sach i fir­mach IT, Mantis.
  • Do zarzą­dza­nia pro­ce­sem nego­cjo­wa­nia i pod­pi­sy­wa­nia umów, wie­le firm i ich praw­ni­ków uży­wa opro­gra­mo­wa­nia Pergamin.
  • No i powszech­ny, z uwa­gi na pra­wo, ePUAP.

Polecam roz­wa­że­nie rezy­gna­cji z pocz­ty elek­tro­nicz­nej do prze­ka­zy­wa­nia doku­men­tów pro­jek­to­wych, nie tyl­ko z uwa­gi na ich bez­pie­czeń­stwo ale głów­nie z uwa­gi na zarzą­dza­nie nimi i kon­tro­le w całym cyklu życia dokumentu. 

Źródła

Paschke, A., & Kozlenkov, A. (2008). A Rule-based Middleware for Business Process Execution. 13.