Dlaczego nie używam poczty elektronicznej do komunikacji w projektach

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…

Czytaj dalejDlaczego nie używam poczty elektronicznej do komunikacji w projektach

Dokumenty w Krajowym Systemie e‑Faktur i nie tylko te dokumenty, e‑podpis

Wstęp

Tym razem opi­su­ję kwe­stie doku­men­tu, doku­men­to­wej posta­ci czyn­no­ści praw­nej i fak­tur w wer­sji elek­tro­nicz­nej, któ­rych wysta­wia­nie jest jak naj­bar­dziej czyn­no­ścią praw­ną, i o inno­wa­cji jaką Minister Finansów ser­wu­je nam od nowe­go roku. 

W 2018 roku opi­sy­wa­łem meto­dy uwia­ry­god­nia­nia tre­ści (doku­men­tów) podsumowując: 

Tego typu meto­dy zabez­pie­cze­nia (tak zwa­ne sys­te­mo­we, w prze­ci­wień­stwie do tech­nicz­nych, jaką jest kwa­li­fi­ko­wa­ny pod­pis elek­tro­nicz­ny), są opar­te na zało­że­niu, że sfał­szo­wa­nie tre­ści doku­men­tu jest nie­moż­li­we (lub jest wykry­wal­ne w 100%) przy zacho­wa­niu usta­lo­nej pro­ce­du­ry dorę­cze­nia doku­men­tu (patrz: Zasada Kerckhoffs?a). Wymagania nakła­da­ne for­mal­nie na pod­miot sta­no­wią­cy Trzecią stro­nę zaufa­nia (nota­riusz) powo­du­ją, że ryzy­ko nie­wy­kry­cia fał­szer­stwa jest bli­skie zeru. Opisane powy­żej meto­dy wymia­ny doku­men­tów nie wyma­ga­ją kosz­tow­ne­go i trud­ne­go w uży­ciu kwa­li­fi­ko­wa­ne­go pod­pi­su elek­tro­nicz­ne­go (źr.: Przesyłki sądo­we dostar­cza­ne przez inter­net czy­li e‑dokumenty c.d.)

Generalnie cho­dzi­ło o alter­na­ty­wę dla e‑podpisu, któ­ry nadal uwa­żam za śle­pą ulicz­kę. Od wie­lu lat, pro­jek­tu­jąc sys­te­my infor­ma­tycz­ne, sto­su­ją zasa­dę mówią­cą. że sys­tem infor­ma­tycz­ny, jako roz­wią­za­nie, nie powi­nien two­rzyć nowych, sztucz­nych bytów infor­ma­cyj­nych, bo im wię­cej takich sztucz­nych (nie ist­nie­ją­cych w rze­czy­wi­sto­ści) bytów powsta­nie, tym bar­dziej sys­tem odsta­je od realiów rze­czy­wi­sto­ści, któ­rą (podob­no) ma wspie­rać. Praktyka poka­zu­je, że pró­by imple­men­ta­cji w sys­te­mach infor­ma­cyj­nych mecha­ni­zmów dale­kich od realiów życia, koń­czy się ogrom­nym kosz­tem i czę­sto po pro­stu porażką. 

Warto mieć świadomość, że strukturalne i stałe w czasie dane, stanowią mniej niż 20% procent wszystkich danych jakie człowiek tworzy, próby stosowania modelu relacyjnego i SQL do pozostałych ponad 80% danych (dokumentów) to droga do klęski. 

On top of this, the­re is sim­ply much more unstruc­tu­red data than struc­tu­red. Unstructured data makes up 80% and more of enter­pri­se data, and is gro­wing at the rate of 55% and 65% per year. (źr.: Structured vs Unstructured Data 101: Top Guide | Datamation)

(wię­cej…)

Czytaj dalejDokumenty w Krajowym Systemie e‑Faktur i nie tylko te dokumenty, e‑podpis

Dokument jako nośnik danych i metoda zarządzania danymi – agregat doskonały [preprint]

Profil UML i meta-model typów dokumentów jako system organizacji danych. Dokument jako kontekstowa struktura informacyjna.  Streszczenie: Opisano sprawdzona w praktyce metodę składowania danych zorganizowanych w dokumenty. Opisana metoda nie ma wad relacyjnego modelu organizacji danych, jakim jest utrata kontekstu danych i komplikacje wywołane brakiem redundancji danych. W pracy tej przedstawiono metodę organizacji danych w dokumenty jako sklasyfikowane agregaty, metodę ich klasyfikacji oraz metamodel ich budowy. Opisany metamodel zakłada, że dokumenty jako struktury danych to zwarte agregaty, klasyfikowane jako opisy obiektów (object) lub wydarzeń (events) co nadaje im zawsze określony i jednoznaczny kontekst. Opisano także metodę projektowania dokumentów jako agregatów kontekstowych, co pozwala zniwelować wskazane wady modelu relacyjnego oraz zagwarantować skuteczność zarządzania informacją. Dodatkowo opisany…

Czytaj dalejDokument jako nośnik danych i metoda zarządzania danymi – agregat doskonały [preprint]

Nowelizacja KPC. Ryzyka dokumentu elektronicznego

Własnie czytam o nowelizacji KPC: Nowe przepisy uznają za dokumenty i dopuszczają jako dowody w sądzie e-maile, esemesy, nagrania audio czy wideo, wręcz ?każdy nośnik informacji umożliwiający zapoznanie się z jej treścią". Te nośniki będą zrównane z pismem papierowym. W elektronicznej formie (tzw. dokumentowej), będzie też można zawierać umowy, składać wiążące oświadczenia. Z tymi oczywistymi ułatwieniami, wynikającymi z postępu techniki i zmian zwyczajów w biznesie, wiąże się niestety też ryzyko. ? W e-korespondencji strony powinny zachować szczególną ostrożność. Adresat e-maila czy nagrany rozmówca może bowiem opacznie odczytywać oświadczenia składane w…

Czytaj dalejNowelizacja KPC. Ryzyka dokumentu elektronicznego

Czym zajmuje się ustawodawca w IT

Obecne ustawy idą w kierunku ustalania metody projektowania systemów teleinformatycznych, opisywania ich szczegółów, metod powstawania. Po co na poziomie ustawy definiować np. pojęcie minimalnych wymagań skoro nie zdefiniowano tego minimum? To już elementy metodyki specyfikowana i tworzenia oprogramowania. Znacznie lepiej by było, gdyby powstał dokument będący np. metodyką dla projektów finansowanych ze środków publicznych. Po co tworzyć ustawowy proces tworzenia systemów teleinformatycznych? Wydaje mi się, że stwierdzenie czy jakikolwiek dokument spełnia ustawowe "minimalne wymagania dla systemu teleinformatycznego" jest niemożliwe bo jak? Jakim testem? Co miało by być wzorcem dla audytu? Ma jednak sens moim zdaniem, by wymagania na systemy były dokumentowane w postaci testów akceptacyjnych. Te są wymierne i "zerojedynkowe". Nie udawałoby się prawnikom dostawców oprogramowania wykazywać zgodności dostarczonego oprogramowania z wymaganiami w postaci OPZ (Opis Przedmiotu Zamówienia) w brzmieniu np. "system ma być wygodny w użyciu" bo każdy go jakoś tam jest wygodny. Należało by w drodze takich testów stwierdzić, czy oprogramowanie daje pożądane efekty. Tu nie będzie pola do popisu dla interpretacji prawnych, często niejednoznacznych zapisów w OPZ-tach. I na koniec: ustawodawca w moich oczach wykazuje, że nie ma kompetencji by tworzyć prawo. Zamiast tworzyć reguły, zaczyna opisywać konkretne metody ich realizacji a to zły kierunek. Po drugie te zbyt szczegółowe regulacje w ustawach wyglądają często na efekty złego lobbingu dostawców technologii. Może warto, by przy rządzie powstał jakiś THINK TANK ukierunkowany na systemowe, całościowe podejście do IT w administracji publicznej. Myślę, że Analiza Systemowa i [[Architektura Korporacyjna]], jako całościowe podejście, a nie lokalne w poszczególnych urzędach, jest na to sposobem. Niestety chyba nie mamy w rządzie kompetentnych ludzi...

Czytaj dalejCzym zajmuje się ustawodawca w IT

Koniec treści

Nie ma więcej stron do załadowania