Tym razem opisuję kwestie dokumentu, dokumentowej postaci czynności prawnej i faktur w wersji elektronicznej, których wystawianie jest jak najbardziej czynnością prawną, i o innowacji jaką Minister Finansów serwuje nam od nowego roku.
W 2018 roku opisywałem metody uwiarygodniania treści (dokumentów) podsumowując:
Tego typu metody zabezpieczenia (tak zwane systemowe, w przeciwieństwie do technicznych, jaką jest kwalifikowany podpis elektroniczny), są oparte na założeniu, że sfałszowanie treści dokumentu jest niemożliwe (lub jest wykrywalne w 100%) przy zachowaniu ustalonej procedury doręczenia dokumentu (patrz: Zasada Kerckhoffs?a). Wymagania nakładane formalnie na podmiot stanowiący Trzecią stronę zaufania (notariusz) powodują, że ryzyko niewykrycia fałszerstwa jest bliskie zeru. Opisane powyżej metody wymiany dokumentów nie wymagają kosztownego i trudnego w użyciu kwalifikowanego podpisu elektronicznego (źr.: Przesyłki sądowe dostarczane przez internet czyli e‑dokumenty c.d.)
Generalnie chodziło o alternatywę dla e‑podpisu, który nadal uważam za ślepą uliczkę. Od wielu lat, projektując systemy informatyczne, stosują zasadę mówiącą. że system informatyczny, jako rozwiązanie, nie powinien tworzyć nowych, sztucznych bytów informacyjnych, bo im więcej takich sztucznych (nie istniejących w rzeczywistości) bytów powstanie, tym bardziej system odstaje od realiów rzeczywistości, którą (podobno) ma wspierać. Praktyka pokazuje, że próby implementacji w systemach informacyjnych mechanizmów dalekich od realiów życia, kończy się ogromnym kosztem i często po prostu 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, there is simply much more unstructured data than structured. Unstructured data makes up 80% and more of enterprise data, and is growing at the rate of 55% and 65% per year. (źr.: Structured vs Unstructured Data 101: Top Guide | Datamation)
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę 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.
Ostatnio pojawiła się w prasie i mediach internetowych dyskusja na temat tego czym jest faktura, niestety bardzo wiele z tych opinii jest pozbawiona podstaw merytorycznych i prawnych, są niejednokrotnie po prostu nieprawdziwe. Biorąc pod uwagę fakt, że wiele tych opinii to opinie wygłaszane przez przedsiębiorców, wyłania się smutny obraz jakości informacji zbieranej metodą wywiadów w toku analiz biznesowych. Studiowanie literatury, cudzych opracowań w roli audytora, analiza pytań i uwag moich klientów to ogromne doświadczenie. Rok temu w artykule Mit o notacji BPMN pisałem o szkodliwości nadmiaru szczegółów na modelach. To wszystko razem skłoniło mnie tym razem do opracowania przykładu diagramu obrazującego proces biznesowy wykonany w notacji BPMN1.
Celem tego artykułu jest pokazanie jak opracować model procesu biznesowego bazując wyłącznie na prawie i tego jak to zrobić zgodnie z notacją BPMN. Pokazano także, że notacja BPMN nie jest narzędziem dokumentowania „wszystkiego co wiemy o procesie”. Istotne jest także to, że notacja BPMN to język wyrazu – narzędzie – a nie metodyka, oraz to że specyfikacja BPMN to nie podręcznik modelowania a jedynie opis pojęć i ich znaczeń oraz przykłady konstrukcji (semantyka i syntaktyka notacji) co nie znaczy, że są to wzorce projektowe. Uważam, że wzorców takich nie ma takich w biznesie, procesów „referencyjnych” też nie ma. Biznes to prawo oraz indywidualne wewnętrzne regulacje.
W ramach wprowadzenia opisano najpierw zasady tworzenia modeli analitycznych z użyciem notacji BPMN.
Notacja BPMN a MDA i UML
Kilka uwag na temat notacji BPMN i kluczowych jej cech. Celem stworzenia tej notacji była komunikacja:
The primary goal of BPMN is to provide a notation that is readily understandable by all business users, from the business analysts that create the initial drafts of the processes, to the technical developers responsible for implementing the technology that will perform those processes, and finally, to the business people who will manage and monitor those processes. Thus, BPMN creates a standardized bridge for the gap between the business process design and process implementation.[BPMN c.1.1. 1]
Generalnie rzecz biorąc (patrz moje wytłuszczenie): diagramy te powinny być zrozumiałe dla tak zwanych ludzi biznesu (bo jeżeli nie są, to są bezużyteczne), stanowią (sformalizowany) szkic dla ludzi odpowiedzialnych za ich implementację. Modele procesów biznesowych stanowią element modeli CIM (Computational Independent Model, model niezależny od technologii IT2).
Poniżej cytuję akapit opisujący istotę podziału modeli na poziomy abstrakcji (dokładności).
As an alternative to full Process Modeling Conformance, there are three conformance sub-classes defined:
Descriptive
Analytic
Common Executable
Descriptive is concerned with visible elements and attributes used in high-level modeling. It should be comfortable for analysts who have used BPA flowcharting tools.
Analytic contains all of Descriptive and in total about half of the constructs in the full Process Modeling Conformance Class. It is based on experience gathered in BPMN training and an analysis of user-patterns in the Department of Defense Architecture Framework and planned standardization for that framework.
Both Descriptive and Analytic focus on visible elements and a minimal subset of supporting attributes/elements.
Common Executable focuses on what is needed for executable process models.
Elements and attributes not in these sub-classes are contained in the full Process Modeling Conformance class. The elements for each sub-class are defined in the next sub clause. [BPMN c.2.2.1.1]
Istotą modelowania procesów z użyciem BPMN jest więc właściwy dobór poziomu szczegółowości. Powyższe ma znaczenie w kontekście umieszczenia tych typów modeli na tle MDA (Model Driven Architecture2) i skorelowania z modelami UML.
Na poziomie CIM powstają modele opisujące mechanizm działania organizacji w całkowitym oderwaniu od technologii IT wspierających tę organizację. Notacja BPMN jest tu wspierana specyfikacją SBVR3 (biznesowy słownik pojęć i reguły biznesowe). Są to wyłącznie modele poglądowe i analityczne.
Kolejny krok to opracowanie modeli wykonywalnych czyli modeli implementacji procesów (wyrażonych w BPMN) z użyciem systemów BPMS (Business Process Management Systems, są to środowiska wykonawcze modeli BPMN common executable). W praktyce te modele mają wersję PIM (wykonane na bazie standardu BPMN/BPEL/XPDL) i PSM czyli dostosowane do środowiska BPMS konkretnego producenta platformy. Jest to ścieżka bazująca całkowicie na notacji BPMN i platformach wykonawczych BPMS.
Proces „tradycyjny” inżynierii oprogramowania oparty na MDA także zaczyna się powstania modelu CIM. Kolejny etap (model) to zawarcie umowy na zakres projektu czyli określenie wymagań. Do tego służy model przypadków użycia (w UML od wersji 2.5 jest jawnie określany jako „dodatkowy”, patrz Figure 6.1 Semantic Areas of UML4):
Rys. Semantic areas of UML 2.5.1
Biorąc pod uwagę zmiany jakie wprowadzono do UML w v.2.5. w zasadzie książki i podręczniki UML napisane przed 2015 rokiem (wejście 2.5. UML), można wyrzucić do kosza.
Po określeniu zakresu produktu, powstaje model PIM stanowiący model mechanizmu działania oprogramowania. Ten model to specyfikacja logiki działania (często stanowi know-how zamawiającego). Po dokonaniu wyboru dostawcy, ten – mając na uwadze technologię której użyje, tworzy model PSM i realizuje implementację (w praktyce, pomija się model PSM, najczęściej powstaje od razu kod na bazie architektury opisanej w modelu PIM).
Zostało to zobrazowane na diagramie poniżej:
Rys. Struktura modeli zgodnie z MDA.
Proces realizacji potrzeb przedsiębiorstwa
Proces realizacji potrzeb przedsiębiorstwa (organizacji) jest inicjowany stwierdzeniem owej potrzeby (wymagana usługa, przedmiot, inne) a kończy się rozliczeniem jej realizacji (dostarczenia). Standardowy proces świadczenia usługi lub dostarczenia produktu jest opisany w Kodeksie Cywilnym5 (zlecenie lub dzieło). Co do zasady więc, na pewnym określonym poziomie szczegółowości, proces ten jest możliwy do opisania bez jakichkolwiek konsultacji z kimkolwiek, treść ustawy wystarczy.
Opis procesu: Pojawianie się potrzeby skutkuje opracowaniem zapytania ofertowego (opis przedmiotu zamówienia jakim może być usługa lub produkt). Z reguły przybiera formę Zapytania ofertowego. Zapytanie takie przekazywane jest potencjalnemu dostawcy, który opracowuje ofertę na realizację tego co opisano w Zapytaniu. Oferta taka jest analizowana, jeżeli zostanie przyjęta, staje się umową pomiędzy Nabywcą a Dostawcą. Umowa ta stanowi podstawę Realizacji zamówienia (jakim jest zaakceptowana oferta). Po zrealizowaniu Zamówienia Dostawca zgłasza gotowość przekazana przedmiotu zamówienia, następuje odbiór. Po odbiorze jest wystawiana faktura na kwotę wskazaną w Ofercie, w określonym terminie ma miejsce płatność. Zamówienie jest zrealizowane i rozliczone.
Opisane aktywności są uzależnione od określonych terminów. Biorąc pod uwagę fakt, że udział biorą w tym procesie dwa podmioty, a całość jest synchronizowana terminami (muszą one być ustalane) proces ten można opisać takim modelem:
Rys. Proces realizacji potrzeby w organizacji. Notacja BPMN.
Powyższy diagram to model analityczny. Model poglądowy byłyby uproszczony do aktywności i dokumentów, zapewne były by to dwa odrębne proste modele (dla Dostawcy i dla Zamawiającego).
Jak widać uwzględniono na tym modelu (model analityczny) kluczowe fakty jakimi są terminy i momenty doręczenia. Wszelkie detale poszczególnych aktywności stanowią najczęściej specyfikę konkretnych podmiotów i są opisane procedurami (np. procedurami ISO z godnie ze stosowną normą). Dokumentowanie tych detali z użyciem kolejnych, szczegółowych diagramów w notacji BPMN z reguły nie ma sensu, gdyż ich adresatami (recenzentami) byli by (są) wykonawcy tych prac, a Ci raczej bez problemu posługują się procedurami w typowej postaci znanej z norm (testy), a nie diagramami BPMN. Umieszczanie dodatkowych detali wprost na tym diagramie doprowadzi do powstania monstrualnego arkusza, trudnego w użyciu.
Na modelach analitycznych posługujemy dwoma kluczowymi pojęciami (BPMN, Annex C Glossary1):
Atomic Activity – An activity not broken down to a finer level of Process Model detail. It is a leaf in the tree-structure hierarchy of Process activities. Graphically it will appear as a Task in BPMN.
Business Process – A defined set of business activities that represent the steps required to achieve a business objective. It includes the flow and use of information and resources.
Atomowym zadaniem, stanowiącym abstrakcję całej aktywności biznesowej prowadzącej do osiągnięcia celu tej pracy, jest aktywność tworząca określony produkt, modelowany w BPMN jako DataObject (notacja BPMN jest oparta na założeniu, że wszelkie efekty pracy są dokumentowane). Innymi słowy nie umieszczamy na modelach procesów detalicznych składowych zadań stanowiących elementy procedury danej aktywności. Procedury modelujemy na osobnych diagramach lub po prostu opisujemy tekstem w odrębnej dokumentacji i powołujemy się na nie.
Co do zasady na modelach analitycznych stosujemy podstawowy, minimalny zestaw symboli opisany w specyfikacji, co gwarantuje ich czytelność i zrozumiałość przez typowego adresata jakim jest osoba, której pracę opisano. Korzystanie z rozszerzonego zestawu symboli (np. symbole detalicznych zadań z ikonami w lewym górnym roku, dodatkowe zdarzenia itp.) nie ma sensu na poziomie modeli analitycznych, gdyż symbole te powstały dla modeli wykonywalnych, przeciętny adresat dokumentacji analitycznej nie poradzi sobie z ich interpretacją. W efekcie po prostu utracimy komunikację w projekcie, co jest niestety bardzo częstym zjawiskiem i przyczyną większości problemów w projektach.
Podsumowanie
Na początkowym, biznesowym, etapie projektów analitycznych celem dokumentacji procesów biznesowych jest opisanie mechanizmu działania organizacji bez zbędnych detali (te zmieniają się dość często). Jeżeli dokumentacja procesów biznesowych wymaga aktualizacji częściej niż raz w roku (a lepiej raz na pięć lat) jest to sygnał, że jest to zła, zbyt szczegółowa dokumentacja.
Literatura naukowa jest pełna opracowań wskazujących, że procesy biznesowe i logika biznesowa to odrębne obszary opisu i modelowania. Notacja BPMN służy do modelowania procesów. Logikę biznesową opisujemy z użyciem reguł biznesowych3, tablic decyzyjnych (patrz artykuł SBVR…), tu jeden z wielu przykładów takich komentarzy:6.
Model procesów biznesowych jest często, w literaturze przedmiotu, nazywany modelem wewnętrznego łańcucha wartości, a nie raz po prostu wewnętrzną strategią realizacji celów rynkowych. Skoro jest to strategia, to nie powinna się ona często zmieniać. W powyższym modelu, uszczegółowienia może wymagań aktywność realizacji zamówienia, gdyż w zależności od podmiotu, może to być realizacja nietrywialnej usługi lub wytworzenia produktu. Była by to tak zwana dekompozycja i powstanie drugi poziom szczegółowości. Pozostałe aktywności to tworzenie określonych dokumentów, a sposób ich powstawania jest określony procedurą i tym jakie pola zawiera dana formatka DataObject. Ten poziom szczegółów opisujemy słownikiem i regułami biznesowymi (SBVR3).
Biorąc pod uwagę fakt, że serwery BPMS są bardzo rzadko wykorzystywane, diagramy BPMN na poziomie common executable praktycznie nie są tworzone. Jeżeli celem tworzenia modeli procesów biznesowych jest analiza przedwdrożeniowa, po modelu analitycznym powstaje umowa w postaci diagramu Przypadków Użycia. Przypadek użycia (patrz artykuł Transformacja…) to odpowiednik atomowej aktywności. Innymi słowy Przypadki Użycia (UML), jako usługi aplikacyjne, wspierają określone aktywności (a konkretnie powstawanie lub przetwarzanie konkretnych dokumentów modelowanych w BPMN jako obiekty DataObject), co opisano na pierwszym diagramie.
Faktura. Diagram procesu biznesowego pokazuje także, że faktura jako dokument, nie jest zobowiązaniem. Zobowiązaniem Dostawcy jest zawarta umowa na dostawę a zobowiązaniem Nabywcy jest płatność po otrzymaniu przedmiotu zamówienia. Zobowiązanie Nabywcy powstaje dopiero po (z reguły pisemnym) odebraniu przedmiotu zamówienia, faktura jest wyłącznie tak zwanym dowodem księgowym, czyli dokumentem stwierdzający jakie kwoty zaksięgować.
________________________________
1.
About the Business Process Model And Notation Specification Version 2.0.2. OMG.org. https://www.omg.org/spec/BPMN/. Published January 13, 2014. Accessed February 10, 2019.
About the Semantics Of Business Vocabulary and Rules Specification Version 1.4. OMG.org. https://www.omg.org/spec/SBVR/. Published May 1, 2017. Accessed February 11, 2019.
4.
About the Unified Modeling Language Specification Version 2.5.1. OMG.org. https://www.omg.org/spec/UML/. Published December 1, 2017. Accessed February 11, 2019.
Domain-Specific Conceptual Modeling Concepts, Methods and Tools, Herausgeber: Karagiannis, Dimitris, Mayr, Heinrich C., Mylopoulos, John (Eds.), ISBN 978 – 3‑319 – 39417‑6, str. 405.
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę 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.
Strona używa plików cookie, aby zapewnić Ci wygodę przeglądania poprzez zapamiętywanie Twoich preferencji i powtarzających się wizyt. Klikając "Akceptuj wszystko", wyrażasz zgodę na użycie WSZYSTKICH plików cookie. Jednakże, możesz odwiedzić "Ustawienia plików cookie", aby zapewnić kontrolowaną zgodę.
Ta strona korzysta z plików cookie, aby poprawić wygodę podczas podczas przeglądania witryny. Pliko cookie, które są sklasyfikowane jako niezbędne, są przechowywane w przeglądarce, ponieważ są niezbędne do działania podstawowych funkcji witryny. Używamy również plików cookie stron trzecich, które pomagają nam analizować i zrozumieć, w jaki sposób korzystasz z tej witryny. Te pliki cookie będą przechowywane w przeglądarce tylko za Twoją zgodą. Możesz również zrezygnować z tych plików cookie. Ale rezygnacja z niektórych z tych plików cookie może mieć wpływ na wygodę przeglądania.
Niezbędne pliki cookie są absolutnie niezbędne do prawidłowego funkcjonowania witryny. Ta kategoria obejmuje tylko pliki cookie, które zapewniają podstawowe funkcje i zabezpieczenia strony. Te pliki cookie nie przechowują żadnych danych osobowych.
Wszelkie pliki cookie, które mogą nie być szczególnie potrzebne do działania witryny i są wykorzystywane w szczególności do gromadzenia danych osobowych użytkowników za pośrednictwem analiz, reklam i innych treści osadzonych, są określane jako niepotrzebne pliki cookie. Wymagane jest uzyskanie zgody użytkownika przed uruchomieniem tych plików cookie w witrynie.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Cookie
Duration
Description
__atuvc
1 year 1 month
AddThis sets this cookie to ensure that the updated count is seen when one shares a page and returns to it, before the share count cache is updated.
__atuvs
30 minutes
AddThis sets this cookie to ensure that the updated count is seen when one shares a page and returns to it, before the share count cache is updated.
bcookie
2 years
LinkedIn sets this cookie from LinkedIn share buttons and ad tags to recognize browser ID.
bscookie
2 years
LinkedIn sets this cookie to store performed actions on the website.
language
session
This cookie is used to store the language preference of the user.
lidc
1 day
LinkedIn sets the lidc cookie to facilitate data center selection.
na_id
1 year 24 days
The na_id is set by AddThis to enable sharing of links on social media platforms like Facebook and Twitter.
ouid
1 year 24 days
Associated with the AddThis widget, this cookie helps users to share content across various networking and sharing forums.
vc
1 year 24 days
The vc cookie is set by addthis.com on sites that allow sharing on social media.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Cookie
Duration
Description
at-rand
never
AddThis sets this cookie to track page visits, sources of traffic and share counts.
browser_id
5 years
This cookie is used for identifying the visitor browser on re-visit to the website.
CONSENT
2 years
YouTube sets this cookie via embedded youtube-videos and registers anonymous statistical data.
uid
1 year 24 days
This is a Google UserID cookie that tracks users across various website segments.
uvc
1 year 1 month
Set by addthis.com to determine the usage of addthis.com service.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
Cookie
Duration
Description
di2
1 year 24 days
AddThis sets this cookie on sites that allow sharing on social media. It is used to track user behaviour anonymously, to create usage trends that will improve relevance to their services and advertising.
loc
1 year 1 month
AddThis sets this geolocation cookie to help understand the location of users who share the information.
um
1 year 24 days
Set by AddThis for registering the user's sharing of content through social media.
VISITOR_INFO1_LIVE
5 months 27 days
A cookie set by YouTube to measure bandwidth that determines whether the user gets the new or old player interface.
YSC
session
YSC cookie is set by Youtube and is used to track the views of embedded videos on Youtube pages.
yt-remote-connected-devices
never
YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
yt-remote-device-id
never
YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
yt.innertube::nextId
never
This cookie, set by YouTube, registers a unique ID to store data on what videos from YouTube the user has seen.
yt.innertube::requests
never
This cookie, set by YouTube, registers a unique ID to store data on what videos from YouTube the user has seen.