Wstęp

Od lat spotykam się w literaturze z zakresu zarządzania, z krytyką poczty elektronicznej jako narzędziem zarządzania czymkolwiek (patrz: Sabotaż…2013). Poczta elektroniczna (podobnie jak pakiety biurowe w ogóle) jest typowym przykładem maksymy: ułatwienie nie zawsze jest ulepszeniem. W kliencie poczty elektronicznej zarówno treść jak i sposób adresowania (co i do kogo, kopia, itp.) nie podlega żadnej standaryzacji ani restrykcji (poczta elektroniczna często służy do wyprowadzania danych z firmy). Jak dodać do tego fakt, że załączniki są niewidoczne w narzędziach do lokalnego wyszukiwania, że mamy na serwerach filtry antyspamowe których reguły nie poddają się kontroli użytkowników, że nie panujemy nad tym co inni mają w swoich skrzynkach pocztowych, to mamy obraz absolutnego braku panowania nad informacją w organizacji i chaosu.

Komunikacja czyli napisać, zapamiętać i doręczyć

Swego czasu dr Paweł Litwiński, prawnik, napisał krytyczny artykuł o zastosowaniu poczty elektronicznej przez adwokatów. Jego tekst był szeroko cytowany przez wielu autorów, tu jeden z takich artykułów. Wybrałem kilka ważnych kwestii:

Praktyka pokazuje, że wielu adwokatów i radców prawnych korzysta z darmowych skrzynek, także tych wprost zastrzegających sobie prawo do skanowania korespondencji. […]

Konflikt pomiędzy obowiązkiem ochrony informacji a warunkami narzuconymi w regulaminach darmowych usług to jedno. Czym innym są kwestie bezpieczeństwa.[…]

? Na logikę, lepiej żeby o materiałach objętych tajemnicą adwokacką nie dowiedział się żaden dostawca, ale z drugiej strony, rzadko której kancelarii prawnej uda się samodzielnie skonfigurować serwer pocztowy tak, aby był równie bezpieczny i nieawaryjny, jak infrastruktura np. Gmaila. Oczywiście, można zlecić to zewnętrznej polskiej firmie, ale wtedy mamy ten sam problem z zaufaniem, co w przypadku korzystania z serwerów np. Google ? zwraca uwagę Piotr Konieczny, ekspert ds. cyberbezpieczeństwa z serwisu Niebezpiecznik.pl. ? Abstrahując więc od aspektów prawnych, rozpatrując problem wyłącznie na płaszczyźnie bezpieczeństwa, tj. ochrony skrzynki przed atakami, moim zdaniem prawnikom niedysponującym budżetem na bezpieczeństwo takim, jaki posiadają profesjonalni dostawcy usług pocztowych, lepiej i prościej byłoby wykorzystać infrastrukturę np. Google?a ? dodaje. Jego zdaniem prawnicy powinni przede wszystkim rozważyć możliwość szyfrowania korespondencji. Wtedy zarówno darmowy, jak i płatny dostawca usług nie będzie w stanie jej podejrzeć. Szyfrowanie jest bez wątpienia najbezpieczniejszym sposobem, ale wiąże się z koniecznością dostarczenia klucza czy hasła odbiorcy, a ten nie zawsze godzi się na takie niedogodności. Co więcej, klienci kancelarii sami często korzystają z darmowych skrzynek. ? I nie rozumieją, dlaczego poufne informacje nie powinny być na nie przesyłane. Moim obowiązkiem jest wówczas poinformować takiego klienta o zagrożeniach z tym związanych. Oczywiście jeśli mimo tego będzie chciał używać takiej skrzynki do korespondencji ze mną, to nie mogę mu tego zabronić ? zwraca uwagę dr Paweł Litwiński. ? Z drugiej strony są również klienci, którzy wręcz wymagają, by w korespondencji z nimi używać jedynie skrzynek założonych na ich serwerach. Tak restrykcyjną mają politykę bezpieczeństwa. Chcąc dla nich pracować, adwokat czy radca musi przystać na te warunki ? dodaje ekspert.

(patrz: Darmowe e-maile nie dla prawników. Dostawca poczty skanuje jej zawartość – 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 podsłuchiwania. Jak uczy­nić naszą kore­spon­den­cję (bar­dziej) nie­jaw­ną?

(Patrz: Bezpieczny jak email czyli wcale – Jarosław Żeliński IT-Consulting – Systemy Informacyjne)

Przypomnę kluczowe tezy powyższego artykułu. Generalnie ważnych dokumentów nie należy przesyłać jako załączniki z dwóch powodów: nie wiemy co sie z nimi dzieje po drodze, nie wiemy czy zostały dostarczone, i kiedy, gdyż bardzo wielu użytkowników email ma wyłączone automatyczne odesłanie potwierdzenia w swojej poczcie, co skutkuje tym, że po prostu jest to niewiarygodna forma potwierdzania. Poniżej schemat pokazujący drogę poczty email:

Droga poczty elektronicznej.

Środkowa część (Internet) to także potencjalne kolejne pośredniczące serwery, nie wiemy co sie na nich dzieje. Tak więc dwie kluczowe wady email to potencjalne skanowanie treści po drodze oraz brak kontroli nad doręczeniem. Czy można inaczej? Owszem: do przekazywania dokumentów można użyć repozytorium (serwera plików) z kontrolowanym dostępem. Poniżej schemat blokowy architektury niemającej ww. wad przesyłania dokumentów mailem:

Dokumenty przekazywane za pośrednictwem repozytorium

Dokumenty “w drodze” nie opuszczają repozytorium: z naszego komputera ładujemy je na serwer wskazując ewentualnie określonego adresata (lub robi to mechanizm obsługujący wymianę treści pomiędzy uczestnikami), określona osoba dostaje mailem informacje, że jest dla niej dokument, żeby go pobrać musi się zalogować do repozytorium. W efekcie treść (plik) nie jest nigdzie narażona na skanowanie, podejrzenie go itp. Tu email służy wyłącznie do monitowania faktu, że jest dokument do nas adresowany i że można do pobrać, co zostanie odnotowane.

Mając nawet proste, dostępne przez internet, repozytorium, można umieścić tam dowolny plik i mailem poinformować adresata (wcześniej zakładamy mu tam konto), że powinien pobrać plik. Serwer rejestruje zarówno moment załadowania pliku jak i jego pobrania, co jest gwarantowanym znakiem czasu nadania i doręczenia. Minus takiego rozwiązania to ręczna obsługa całego procesu, plus to panowanie nad wszystkim i bezpieczeństwo.

Sprawdzonym, od dawna, na rynku pomysłem jest system workflow z udostępnianym repozytorium, automatyzujący cały ten proces:

Architektura systemu wymiany danych z Repozytorium.

Uogólniając można go przedstawić jako serwer usług:

System workflow sterowany regułami

System doręczeń to tak naprawdę funkcjonalność aplikacji typu workflow zorientowanego na zadania (task manager), mającej możliwość udostępnienia jej kontrahentom. Funkcjonalność taką ma wiele systemów CRM, systemów helpdesk, wiele repozytoriów pozwala na skonfigurowanie subskrypcji zdarzeń powiązanych z dokumentami. Zbudowanie takiego systemu opartego na regułach, zamiast na macierzach praw dostępu do dokumentów, znakomicie upraszcza całość i dodatkowo podnosi bezpieczeństwo (bardzo ułatwia wdrażanie RODO) . Ciekawą funkcjonalnością jest możliwość blokowania możliwości pobrania dokumentu na lokalny dysk, dozwolone jest jedynie przeglądanie treści w przewijanym oknie (oferują to niektóre tego typu systemy).

Systemy tego typu są także wdrażane jako zamiennik poczty elektronicznej wewnątrz organizacji. Tam gdzie podstawowym wewnętrznym systemem komunikacji jest poczta elektroniczna problemem są ginące dokumenty oraz brak dostępu do dokumentów (skrzynek) osób niedostępnych, będących poza firmą (chroba, delegacja itp.). Generalnie poczta jako “skład dokumentów” ma tę podstawową wadę, że dokumenty są rozproszone i zarzadzanie nimi w jednolity sposób jest niemożliwe. Stosowanie współdzielonych dysków nie rozwiązuje całkowicie problemu, bo po pierwsze nie da się budować reguł dostępu, po drugie wymiana dokumentów z osobami spoza firmy jest bardzo trudna (np. wymaga uruchomenia VPN co jest trudne, wymaga ingerencji w cudzy komputer, i coraz częściej nie jest to możliwe w wielu firmach).

Tak więc poczta elektroniczna, jako swobodna komunikacja między ludźmi owszem, jest przydatna. Jednak jako narzędzie do zarządzania komunikacją, przepływem treści, dokumentów ich wydań i doręczeń, jest bardzo zawodna. A warto wiedzieć, że prawna ochrona know-how w UE, czyli w Polsce także, to przede wszystkim obowiązek ochrony treści przez podmiot chroniący (udostępniający) takie dane. Dlatego dość kuriozalnie wygląda każda firma, która wysyłając mailem umowę o poufności (NDA) wysyła potem także mailem te “poufne” dokumenty…

Na zakończenie

Rozwiązań, realizujących opisane wyżej funkcje, nie brakuje. Główną blokadą ich wdrażania jest przyzwyczajenie do swobody. Jednak poczta elektroniczna jest klasycznym przykładem tego, że ułatwienie nie zawsze jest ulepszeniem. O wdrażaniu systemów workflow, panujących nad komunikacją i jej poufnością, mówi się podobnie jak o systemach kopii zapasowych: firmy dzielą się na te, które wdrożyły skuteczny workflow i na te które wdrożą.

Kilka przykładów (nie oferuję tych systemów, to nie są rekomendacje a przykłady):

  • Biuro księgowe, które mnie obsługuje, odeszło od prostego systemu FK i komunikacji mailowej (przekazywanie dokumentów kosztowych, wysyłanie klientom deklaracji podatkowych, raportów itp.), obecnie korzysta z podatkipodatki.pl.
  • Zaczynałem jak wielu od poczty elektronicznej, po kilku przygodach z dokumentami w projektach (kto, co, kiedy i komu) szybko wdrożyłem darmowy, potem supportowany osTicket (na początek bardzo dobry i łatwy we wdrożeniu).
  • Z uwagi na specyfikę mojej pracy (praca polegająca na zbieraniu danych i tworzeniu raportów z analiz, ich recenzowanie przez klientów) używam obecnie do komunikacji bardziej zaawansowanego oprogramowania PostMania.
  • U wielu klientów spotykam, popularny w serwisach i firmach IT, Mantis.
  • Do zarządzania procesem negocjowania i podpisywania umów, wiele firm i ich prawników używa oprogramowania Pergamin.
  • No i powszechny, z uwagi na prawo, ePUAP.

Polecam rozważenie rezygnacji z poczty elektronicznej do przekazywania dokumentów projektowych, nie tylko z uwagi na ich bezpieczeństwo ale głównie z uwagi na zarządzanie nimi i kontrole w całym cyklu życia dokumentu.

Źródła

Hepburn, B., & Andersen, H. (2021). Scientific Method. In E. N. Zalta (Ed.), The Stanford Encyclopedia of Philosophy (Summer 2021). Metaphysics Research Lab, Stanford University. https://plato.stanford.edu/archives/sum2021/entries/scientific-method/
Ozkaya, M. (2023, April 9). Microservices Architecture. Design Microservices Architecture with Patterns & Principles. https://medium.com/design-microservices-architecture-with-patterns/microservices-architecture-2bec9da7d42a
Weiss, M., & Hari, A. (2004). ICDM - an Integrated Methodology for the Conceptual Design of New Systems. https://www.academia.edu/59514794/ICDM_an_Integrated_Methodology_for_the_Conceptual_Design_of_New_Systems
Włodarska-Dziurzyńska, K. (2012). Pojęcie produktu. Nieuczciwe praktyki rynkowe : ocena regulacji, 141–143. https://ruj.uj.edu.pl/server/api/core/bitstreams/c5d331c9-8945-4f12-9a9b-12eddee0be30/content
Mahesh, B. (2019). Machine Learning Algorithms -A Review. https://doi.org/10.21275/ART20203995
Martin, R. C., & Martin, R. C. (2018). Clean architecture: a craftsman’s guide to software structure and design. Prentice Hall.
Foote, B., & Yoder, J. (1997). Big Ball of Mud. Department of Computer Science University of Illinois at Urbana-Champaign 1304 W. Springfield Urbana, IL 61801 USA. https://www.researchgate.net/publication/2938621_Big_Ball_of_Mud
Alencar, F. (2000). Closing the GAP between organizational requirements and object oriented modeling. Journal of the Brazilian Computer Society. https://www.academia.edu/83364710/Closing_the_GAP_between_organizational_requirements_and_object_oriented_modeling
Rumpe, B. (2007). Model-driven development of complex software: A research roadmap. https://www.academia.edu/16456630/Model_driven_development_of_complex_software_A_research_roadmap
Harmon, P. (2010, December 14). What is a Business Process. BPTrends, 8(21), 6. http://www.bptrends.com/publicationfiles/advisor20101214.pdf
Harmon, P., & Garcia, J. (2020). The States of the Business Process Management Process 2020 (No. 2020). BP Trends Associations. www.bptrends.com
Harmon, P. (2016). The State of Business Process Management 2016. BT Trends. https://www.club-bpm.com/Contenido/Estudios/BPT-Survey-Report.pdf
Nanayakkara, C. (2023, July 7). Microservices Patterns: The Saga Pattern. Cloud Native Daily. https://medium.com/cloud-native-daily/microservices-patterns-part-04-saga-pattern-a7f85d8d4aa3
Gaiardelli, S., Spellini, S., Panato, M., Tadiello, C., Lora, M., Cheng, D. S., & Fummi, F. (2024). Enabling Service-oriented Manufacturing through Architectures, Models and Protocols. IEEE Access, 1–1. https://doi.org/10.1109/ACCESS.2024.3385634
Huang, S.-C. (2006). A semiotic view of information: Semiotics as a foundation of LIS research in information behavior. Proceedings of the American Society for Information Science and Technology, 43(1), 1–17. https://doi.org/10.1002/meet.1450430166
Nuninger, L., Verhagen, P., Libourel, T., Opitz, R., Rodier, X., Laplaige, C., Fruchart, C., Leturcq, S., & Levoguer, N. (2020). Linking Theories, Past Practices, and Archaeological Remains of Movement through Ontological Reasoning. Information, 11, 338. https://doi.org/10.3390/info11060338
Machado, I. (2015). Graphic argumentation: diagrammatic modeling in the communication of science. Communicating and Evaluating Science. Covilhã: Labcom, 177–202. https://www.researchgate.net/profile/Catarina_Gracio_De_Moura/publication/324314608_Communicating_and_Evaluating_Science/links/5c6485c8299bf1d14cc4bc1c/Communicating-and-Evaluating-Science.pdf#page=181
Machado, I. (n.d.). Graphic argumentation: diagrammatic modeling in the. Communication and Evaluating Science, 177–202. Retrieved April 11, 2024, from https://www.academia.edu/download/92934020/Irene_Machado.pdf
Jerzy Zajadło. (2019). Banał formuły “dura lex sed lex.” Banał formuły “dura lex sed lex,” R. 64, nr 5, 5–12. https://palestra.pl/pl/czasopismo/wydanie/5-2019/artykul/banal-formuly-dura-lex-sed-lex
Korycka-Zirk, M., & Dobrzeniecki, K. (2018). Logika dla prawników: kompendium i zadania (Wydanie II rozszerzone). Towarzystwo Naukowe Organizacji i Kierownictwa “Dom Organizatora.”
Lewandowski, S., & Malinowski, A. (Eds.). (2002). Logika dla prawników. Wydaw. Prawnicze “LexisNexis.”
Lewandowski, S., Machińska, H., Malinowski, A., Petzel, J., & Pełka, M. (Eds.). (2022). Logika dla prawników (Wydanie 13). Wolters Kluwer.
Lewandowski, S., Malinowski, A., & Petzel, J. (Eds.). (2021). Logika dla prawników: słownik encyklopedyczny (3. wydanie zaktualizowane i rozszerzone). Wolters Kluwer.
Friedman, J. (1997). What’s wrong with Libertarianism. Critical Review, 11(3), 407–467. https://doi.org/10.1080/08913819708443469
Singla, A., Nathan, V. T., & Vageesh, S. (2016). Model Based Self‐Learning System Engineering Approach. INCOSE International Symposium, 26(s1), 219–233. https://doi.org/10.1002/j.2334-5837.2016.00327.x
Sarnowski, J. (2022). Podatki w krajach nordyckich a gospodarka i dobrobyt. Doradztwo Podatkowe - Biuletyn Instytutu Studiów Podatkowych, 5(309), 4–14. https://doi.org/10.5604/01.3001.0015.8617
Ackoff, R. L., Magidson, J., Addison, H. J., & Ehrlich, A. (2007). Projektowanie ideału: kształtowanie przyszłości organizacji. Wyższa Szkoła Przedsiębiorczości i Zarządzania im. Leona Koźmińskiego : Wydawnictwa Akademickie i Profesjonalne. https://repozytorium.kozminski.edu.pl/pl/pub/3442
Babalola, V. (2016). Public Private Partnership: Imperative in Educational Planning and Management for Human Security in Nigerian Schools. 6.
Keet, C. M., & Fillottrani, P. R. (2015). An Analysis and Characterisation of Publicly Available Conceptual Models. In P. Johannesson, M. L. Lee, S. W. Liddle, A. L. Opdahl, & Ó. Pastor López (Eds.), Conceptual Modeling (Vol. 9381, pp. 585–593). Springer International Publishing. https://doi.org/10.1007/978-3-319-25264-3_45
Busboom, A. (2024). Automated generation of OPC UA information models — A review and outlook. Journal of Industrial Information Integration, 100602. https://doi.org/10.1016/j.jii.2024.100602
Michalak. (n.d.). Ustawa o prawie autorskim i prawach pokrewnych. Komentarz. Wolters Kluwer. Retrieved March 23, 2024, from https://www.ksiegarnia.beck.pl/media/product_custom_files/1/8/18361-ustawa-o-prawie-autorskim-i-prawach-pokrewnych-komentarz-arkadiusz-michalak-fragment_1.pdf
Brambilla, M., Cabot, J., & Wimmer, M. (2012). Model-driven software engineering in practice. Morgan & Claypool.
Boisot, M., & Canals, A. (2004). Data, information and knowledge: have we got it right? Journal of Evolutionary Economics, 14(1), 43–67. https://doi.org/10.1007/s00191-003-0181-9
Chen, M., Ebert, D., Hagen, H., Laramee, R. S., Van Liere, R., Ma, K.-L., Ribarsky, W., Scheuermann, G., & Silver, D. (2008). Data, information, and knowledge in visualization. IEEE Computer Graphics and Applications, 29(1), 12–19. https://ieeexplore.ieee.org/abstract/document/4736452/
Floridi, L. (2005). Is Semantic Information Meaningful Data? Philosophy and Phenomenological Research, 70(2), 351–370. https://doi.org/10.1111/j.1933-1592.2005.tb00531.x
Zins, C. (2007). Conceptual approaches for defining data, information, and knowledge. Journal of the American Society for Information Science and Technology, 58(4), 479–493. https://doi.org/10.1002/asi.20508
Foehr, M., Vollmar, J., Calà, A., Leitão, P., Karnouskos, S., & Colombo, A. (2017). Engineering of Next Generation Cyber-Physical Automation System Architectures. In Multi-Disciplinary Engineering for Cyber-Physical Production Systems: Data Models and Software Solutions for Handling Complex Engineering Projects (pp. 185–206). https://doi.org/10.1007/978-3-319-56345-9_8
(N.d.).
(N.d.).
Therefore, use a Repository, the purpose of which is to encapsulate all the logic needed to obtain object references. The domain objects won’t have to deal with the infrastructure to get the needed references to other objects of the domain. They will just get them from the Repository and the model is regaining its clarity and focus. (n.d.).
Therefore, a new concept is necessary to be introduced, one that help to encapsulate the process of complex object creation. This is called Factory. Factories are used to encapsulate the knowledge necessary for object creation, and they are especially useful to create Aggregates. When the root of the Aggregate is created, all the objects contained by the Aggregate are created along with it, and all the invariants are enforced. (n.d.).
Therefore, use Aggregates. An Aggregate is a group of associated objects which are considered as one unit with regard to data changes. The Aggregate is demarcated by a boundary which separates the objects inside from those outside. Each Aggregate has one root. The root is an Entity, and it is the only object accessible from outside. The root can hold references to any of the aggregate objects, and the other objects can hold references to each other, but an outside object can hold references only to the root object. If there are other Entities inside the boundary, the identity of those entities is local, making sense only inside the aggregate. (n.d.).
A Service should not replace the operation which normally belongs on domain objects. We should not create a Service for every operation needed. But when such an operation stands out as an important concept in the domain, a Service should be created for it. There are three characteristics of a Service: 1. The operation performed by the Service refers to a domain concept which does not naturally belong to an Entity or Value Object. 2. The operation performed refers to other objects in the domain. 3. The operation is stateless. (n.d.).
Entities are important objects of a domain model, and they should be considered from the beginning of the modeling process. It is also important to determine if an object needs to be an entity or not, which is discussed in the next pattern. (n.d.).
(N.d.).
(N.d.).
However, when domain-related code is mixed with the other layers, it becomes extremely difficult to see and think about. Superficial changes to the UI can actually change business logic. To change a business rule may require meticulous tracing of UI code, database code, or other program elements. Implementing coherent, model-driven objects becomes impractical. (n.d.).
In an object-oriented program, UI, database, and other support code often gets written directly into the business objects. Additional business logic is embedded in the behavior of UI widgets and database scripts. This some times happens because it is the easiest way to make things work quickly. (n.d.).
Patrz architektura heksagonalna. (n.d.).

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Ten post ma jeden komentarz

  1. “E-maile. To przez nie pędzimy rano, aby uwolnić nasze umysły od “ważnej pracy”. To właśnie nimi denerwujemy się po powrocie z dwutygodniowych wakacji, ponieważ wiemy, że będziemy przytłoczeni ogromną ilością wiadomości. To właśnie zagraża powodzeniu naszych projektów i właśnie dlatego powinniśmy z nich zrezygnować, jeśli chodzi o zarządzanie projektami…”

    https://www.stackfield.com/blog/email-in-project-management-126

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.