Wprowadzenie

Artykuł poświęcono problematyce specyfikacji danych w modelach procesów biznesowych, opracowanych z wykorzystaniem notacji BPMN, która ma realne szanse stać się powszechnie akceptowanym standardem modelowania procesów. Opracowanie zakłada znajomość wspomnianej notacji na poziomie wystarczającym do poprawnej interpretacji studium przypadku dotyczącego procesu akceptacji prac na obiekcie telekomunikacyjnym². Celem publikacji jest zaproponowanie zestawu notacji umożliwiających wsparcie modeli procesów biznesowych organizacji w zakresie modelowania struktury dokumentów oraz danych. Wartość dodaną stanowi w szczególności opracowanie i egzemplifikacja profilu UML na potrzeby modelowania danych BPMN.

Efektywność metod zarządzania organizacjami gospodarczymi jest nieodmiennie tematem nie tylko o ponadprzeciętnym znaczeniu praktycznym, ale także o dużej atrakcyjności dla środowiska naukowego. Jednym z najbardziej charakterystycznych paradygmatów, wychodzących naprzeciw wyzwaniom nowoczesnej gospodarki, jest podejście procesowe. Ciągły wzrost złożoności organizacji, komplikacja ich interakcji z otoczeniem, rosnąca presja konkurencyjna, obejmująca kolejne aspekty funkcjonowania przedsiębiorstw globalizacja oraz nieustanny rozwój technologii - w szczególności informatycznych, lecz również produkcyjnych - dostarczają podmiotom gospodarczym, które dokonały transformacji w kierunku organizacji procesowej, argumentów za słusznością wybranej drogi. Praktyka wskazuje, iż udana transformacja jest procesem długofalowym i wiąże się z wypracowaniem kultury organizacyjnej, która niejednokrotnie dalece odbiega od dotychczasowej. Wdrażanie koncepcji zarządzania procesowego w organizacji wymaga w szczególności³:

• zidentyfikowania oraz monitorowania celów, procesów i działań organizacji (tworzenia map i modeli procesów);
• wyodrębnienia zespołów procesowych i właścicieli procesów oraz nadania im odpowiednich uprawnień;
• przekształcenia pionowych struktur organizacyjnych w struktury poziome (procesowe);
• zastąpienia w opisie organizacji stanowisk pracy rolami organizacyjnymi;
• zdefiniowania ról i prowadzenia polityki informacyjnej dotyczącej nowych obowiązków pracowniczych;
• określenia kryteriów oceny procesów oraz wdrożenia systemu gromadzenia, przetwarzania i przesyłania informacji.

Specyfikowanie procesów biznesowych

Realizacja kolejnych etapów wdrażania koncepcji zarządzania procesowego w organizacji - jak również późniejsze zwiększanie poziomu jej dojrzałości procesowej - wiąże się z wykorzystaniem licznych technik specyfikacji oraz pomiaru charakterystyk poszczególnych procesów. W zakresie specyfikacji procesów biznesowych najbardziej zróżnicowanym wsparciem charakteryzuje się dyscyplina modelowania procesów biznesowych (por. tabela 1). Wykorzystuje ona zarówno klasyczne standardy, stosowane pierwotnie najczęściej w analizie i projektowaniu systemów informatycznych, a później zaadaptowane dla potrzeb modelowania biznesowego, jak i rozwiązania tworzone od początku z myślą o użyciu ich w modelowaniu procesów biznesowych. O ile różnorodność standardów jest cenna w dyskursie naukowym i przyczynia się do rozwoju dziedziny, o tyle w codziennych zastosowaniach okazuje się kłopotliwa. Stąd duże nadzieje na unifikację dyscypliny modelowania procesów biznesowych pokłada się w notacji BPMN, zyskującej coraz większą popularność i firmowanej przez organizację OMG (Object Management Group), która ma w tym zakresie znaczące dokonania - w szczególności rozwinięcie powszechnie akceptowanego w informatyce standardu UML (Unified Modeling Language).

Należy jednak zaznaczyć, że choć to wizualne sposoby opisu procesów i środowiska biznesowego cieszą się znacznym zainteresowaniem praktyków i badaczy, nie powinno się zapominać także o innym aspekcie specyfikacji, jakim jest strukturalny zapis składowych procesu w metajęzykach opartych na formacie XML. O ile notacje graficzne są ukierunkowane na dostarczenie zrozumiałych dla wszystkich interesariuszy modeli procesów biznesowych (a w zależności od zastosowanej notacji - także ich kontekstu biznesowego, wyrażonego np. interakcjami czy dokumentami), o tyle rodzina języków definiowania procesów umożliwia wymianę modeli procesów biznesowych pomiędzy narzędziami różnych dostawców oraz zapewnia wykonywalność procesów biznesowych w drodze aranżacji (orchestration) bądź choreografii (choreography) opublikowanych usług internetowych, ujętych w danym procesie. Do najbardziej rozpoznawalnych języków z tej grupy zaliczyć należy w szczególności XPDL 2.2 (XML Process Definition Language) oraz WS-BPEL 2.0 (Web Services Business Process Execution Language).

Problematyka danych w specyfikowaniu procesu biznesowego

Kwestia modelowania danych dla definicji procesów biznesowych dotyczy bez wątpienia takiego przedstawienia tych danych, aby zespół programistów, który dany proces będzie implementował w silniku procesów biznesowych, prawidłowo zinterpretował modele dostarczone przez analityków i zaprojektował system informatyczny spełniający oczekiwania biznesowe. Notacja BPMN z założenia koncentruje się na dynamicznym aspekcie danych - tj. na uzupełnieniu modelu procesu o obiekty danych generowane lub wykorzystywane przez poszczególne zadania procesowe. Kwestie strukturalnych relacji pomiędzy dokumentami, budowy modelu dokumentów lub danych w organizacji i zarządzania złożonością modelu danych z założenia pozostają poza obszarem zainteresowania BPMN. Zatem analityk biznesowy jest w tym aspekcie zdany na potencjalne notacje komplementarne w stosunku do samego standardu BPMN.

Warto w tym miejscu rozważyć dwa zasadnicze problemy, które trudno jednoznacznie zakwalifikować do zagadnień modelowania procesów czy tworzenia systemów, jednakże są one z punktu widzenia działania biznesu bardzo istotne - tym bardziej, że analizy dotyczące atrybutów w systemach workflow dotykają coraz szerszych obszarów badawczych. Wspomniane zintensyfikowanie wysiłków badawczych skutkuje kolejnymi propozycjami podziału danych, następuje także próba identyfikacji źródeł ich pochodzenia (zewnętrzne i wewnętrzne) oraz systematyzacji w ściśle określonych formatach⁴. Interesujące są również analizy sposobu „przemieszczania się” danych, które mogą przechodzić zgodnie z kierunkiem przepływu zadań (Interior Data Flow) lub w kierunku przeciwnym (Exterior Data Flow)⁵. Badanie komercyjnych systemów przepływu pracy powoduje także konieczność podjęcia dyskusji dotyczącej danych w kontekście użytecznej analizy procesów biznesowych workflow.

Pierwszym istotnym zagadnieniem z tego zakresu jest sposób weryfikacji danych, które z definicji są niemodyfikowane, ale wpłynęły na nie zmiany w otoczeniu. Przykładem mogą być dane dotyczące pracowników, którzy posiadają w systemie workflow swój unikalny identyfikator (UserID). Każdy uczestnik procesów poprzez ten identyfikator jest przypisany do odpowiedniej grupy organizacyjnej, a także posiada swój profil, definiujący jego prawa i zakres dostępu do funkcjonalności systemu. Gdy pracownik zostaje awansowany lub zmienia stanowisko pracy w ramach przedsiębiorstwa, zmianie ulega także zakres jego obowiązków. Trzeba wówczas dokonać aktualizacji jego statusu organizacyjnego w systemie przepływu pracy. Techniczna zmiana danych typu: zespół procesowy, profil, prawa dostępu do zasobów itp. jest prosta w realizacji i dokonuje jej zazwyczaj administrator systemu workflow. Trudniejsza jest weryfikacja zadań, w które dany pracownik jest zaangażowany. Jeśli zmiana zakresu obowiązków powoduje, że proces, w którym pracownik bierze udział, nie jest już związany tematycznie z zakresem jego obowiązków, musi wówczas nastąpić przepisanie „starych” obowiązków do innej osoby, która przejmie ich wypełnianie. Nie można dopuścić do sytuacji, w której proces przestanie być realizowany z powodu zaniku odpowiedzialności za dany etap.

Kolejny problem w systemach workflow dotyczy danych dodawanych ręcznie lub półautomatycznie przez użytkowników aplikacji. Trzeba bowiem zaznaczyć, że oprócz parametrów służących do monitoringu procesów i administrowania nimi, systemy przepływu pracy zawierają informacje dotyczące zawartości merytorycznej procesowanych zleceń, np. w firmie telekomunikacyjnej mogą to być: nazwa, numer i lokalizacja obiektu telekomunikacyjnego, opis wykonanej czynności itp. Usystematyzowanie tych danych pod względem treści i typu ułatwia ich kontrolę i tworzenie użytecznych zestawień dotyczących zawartości merytorycznej zadań workflow. Przykładowo, można sformułować następujące pytanie: ile razy w ciągu roku wykonano modyfikację mocy nadawczej na obiekcie telekomunikacyjnym X? Udzielenie odpowiedzi wymaga selekcji rejestru zdarzeń pod kątem wykonywanych czynności (modyfikacja mocy nadawczej), a także nazwy obiektu (obiekt X). Dalsze rozbudowanie pytania o kolejne szczegóły wykonanej czynności (przykładowo: czy wykonano obniżanie, czy podwyższanie mocy; jaka była przyczyna takich aktywności?) wymaga wprowadzenia wszystkich potrzebnych informacji do systemu workflow. Może jednak dojść do tego, że czas poświęcany przez pracowników na wypełnianie wymaganych pól w formatce narzędzia workflow będzie bardzo wydłużony. Odciąganie inżynierów od działalności merytorycznej na rzecz działań biurowych rodzi ich frustrację i powoduje zmęczenie. Dlatego na etapie tworzenia systemu i modelowania procesów biznesowych trzeba mieć świadomość, jaka jest planowana zawartość raportów i statystyk, które w przyszłości będą generowane. Niektórzy menadżerowie stosują taktykę, którą można opisać następująco: rejestrujmy wszystko, co można, a potem wybierzemy to, co będzie nam potrzebne. Ta strategia jest zgubna i świadczy o braku merytorycznych podstaw do kierowania procesami biznesowymi oraz zarządzania zasobami ludzkimi w firmie.

Proces akceptacji prac na obiekcie telekomunikacyjnym - studium przypadku

Od kilkunastu miesięcy operatorzy telefonii komórkowej prowadzą intensywne prace związane z rekonfiguracją infrastruktury technicznej swoich sieci. Tak szeroko zaplanowane inwestycje związane są z erą szybkiego internetu, którego dostarczenie do każdego zakątka kraju stało się dla operatorów największym priorytetem. Szybki transfer danych, stały dostęp do zasobów internetowych oraz mobilne usługi sieciowe wymagają skokowych zmian w technologii telekomunikacyjnej, która obecnie zapewnia dobrą jakość usług głosowych, jednakże nie jest w stanie sprostać wymaganiom klientów w zakresie transmisji danych. Dodatkowo na rynku pojawiają się coraz nowocześniejsze terminale abonenckie, takie jak smartfony i tablety, co stanowi dodatkowy czynnik zmuszający operatorów do szybkiej modyfikacji sieci komórkowej. Tradycyjna technologia, oparta na komutacji kanałów, zostaje zastąpiona technologią pakietową IP (Internet Protocol) po to, aby te najbardziej atrakcyjne spośród możliwości terminali abonenckich można było w pełni wykorzystać. Jednakże aby tak się stało, trzeba zmodyfikować całą sieć komórkową - co w praktyce wymaga wymiany całego sprzętu operatorów, począwszy od węzłów naziemnych (stacje bazowe, siłownie elektryczne, sprzęt transmisyjny), poprzez okablowanie, aż po komponenty wyniesione (linie radiowe, anteny).

Ponieważ operatorzy nie posiadają zasobów ludzkich, które byłyby w stanie szybko dokonać modyfikacji sieci, większość prac wykonywanych jest przez tzw. firmy podwykonawcze. Firmy te, w ramach podpisanych z operatorami umów, otrzymują od nich zlecenie wykonania prac na danym obiekcie. Ten proces wymaga kontroli działań firm podwykonawczych, po to, aby każdy zmodyfikowany obiekt ponownie włączać do sieci komórkowej i zacząć świadczyć nowe usługi na danym obszarze. Na rysunku 1 przedstawiono zdarzenia biznesowe, zadania i dokumenty, które tworzą proces akceptacji przez operatora prac wykonanych przez firmę podwykonawczą.

Rysunek 1. Proces akceptacji prac na obiekcie telekomunikacyjnym

Źródło: opracowanie własne.

Firma podwykonawcza otrzymuje od operatora sieci telekomunikacyjnej informację o konieczności przeprowadzenia rekonfiguracji danego obiektu. Zamówienie wykonania prac, Wytyczne instalacyjne oraz Lista testów (do wykonania na zmodernizowanym obiekcie) stanowią zestaw dokumentów, które umożliwiają zaplanowanie, a następnie wykonanie działań w terenie. Po zakończeniu prac, które polegają na deinstalacji urządzeń w starej, a następnie instalacji w nowej technologii, firma podwykonawcza jest zobowiązana przeprowadzić podstawowe testy dostarczonych urządzeń oraz sporządzić Dokumentację poinstalacyjną dotyczącą wykonanych działań. Fakturę (FV) za przeprowadzone prace przesyła się operatorowi pocztą elektroniczną, a Dokumentacja poinstalacyjna zostaje umieszczona w Systemie WFM operatora, do którego firma podwykonawcza ma dostęp przez przeglądarkę internetową. System workflow (WFM) wspiera obieg pracy, dokumentów i zadań w wielu procesach operatora, również w procesie akceptacji prac.

Po otrzymaniu Dokumentacji poinstalacyjnej oraz faktury (nazywanych łącznie po dostarczeniu do operatora Dokumentacją) operator dokonuje ich weryfikacji. W przypadku wątpliwości dotyczących dokumentów operator zwraca je do firmy podwykonawczej w celu uzupełnienia braków. Gdy dokumentacja zostanie zaakceptowana przez operatora, obie strony wyznaczają datę wspólnego odbioru prac na obiekcie. W trakcie wspólnej wizyty w terenie przedstawiciel operatora dokonuje, zgodnie z Procedurą akceptacyjną, weryfikacji prac (ułożenie okablowania, jakość montażu sprzętu, czystość) oraz sprawdza, czy zainstalowany sprzęt jest sprawny. Wynikiem tych działań jest Dokumentacja poodbiorowa. Jej zawartość to protokół inspekcji technicznej, stanowiący podsumowanie wykonanego odbioru prac, wraz z listą usterek, które zostały wskazane po szczegółowej kontroli. Dokumentacja poodbiorowa zostaje wprowadzona do Systemu WFM operatora, dzięki czemu jest dostępna zarówno dla zainteresowanych pracowników operatora, jak i - przez przeglądarkę internetową - dla firmy podwykonawczej (należy w tym momencie dodać, że systematyczna obsługa systemu WFM umożliwia śledzenie przebiegu procesu odbioru instalacji sprzętu na danym obiekcie). Na tym etapie procesu pracownicy operatora, którzy brali udział w odbiorze prac instalacyjnych, uzupełniają także bazę danych Systemu Magazynowego o informacje dotyczące sprzętu zainstalowanego na danym obiekcie. Dodatkowo informacje o przebiegu procesu akceptacji zostają wpisane do Systemu Zarządzania Projektem, którego nadrzędnym celem jest umożliwienie kadrze menedżerskiej zarządzania harmonogramem projektu rekonfiguracji całej sieci operatora.

Skorygowanie zidentyfikowanych w trakcie odbioru usterek może mieć charakter priorytetowy, co w praktyce oznacza konieczność wykonania poprawek przez firmę instalacyjną, uzupełnienia Dokumentacji i ponownego zgłoszenia gotowości prac do odbioru. W przypadku braku usterek lub niskiego priorytetu ich usunięcia obiekt zostaje przeznaczony do dalszych prac prowadzących ostatecznie do komercyjnego uruchomienia. Gdy odbiór prac nie wykazuje usterek priorytetowych, wówczas operator wystawia Certyfikat odbioru, czyli potwierdza zgodność wykonanych prac z zamówieniem i Wytycznymi instalacyjnymi. Usterki o niskim priorytecie zostają usunięte, a następnie informacja o pełnej gotowości obiektu do komercyjnego włączenia jest wpisywana do Systemu WFM operatora oraz Systemu Zarządzania Projektem. Ostatecznie operator reguluje firmie podwykonawczej Płatność za wykonaną pracę.

Dynamiczne ujęcie problematyki danych w procesie akceptacji prac

W notacji BPMN obiektowi danych przypisuje się jednoznaczną nazwę. Diagramy mogą de facto ujmować także stany obiektów danych, gdyż każdej referencji do obiektu danych analityk biznesowy może przypisać opcjonalny stan. W trakcie realizacji procesu biznesowego może ulec on zmianie, np. FV [Wystawiona] -> FV [Zapłacona]. Dynamiczne ujęcie problematyki danych zakłada też określanie charakteru danych jako wejściowych bądź wynikowych, jeśli dane przetwarzane (używane) w procesie pochodzą z zewnętrznego źródła (są przesyłane do zewnętrznego źródła), np. innego procesu albo repozytorium w rodzaju bazy danych. Takimi elementami na rysunku 1 są np. dokumenty na wejściu procesu, które firma podwykonawcza otrzymuje od operatora w celu wykonania zleconych prac.

W trakcie wykonywania procesu biznesowego dane są wykorzystywane do realizacji czynności (podprocesów, zadań) procesowych, co ilustruje użycie asocjacji danych. Na rysunku 1 powyższa zasada została zastosowana wielokrotnie, np. obiekt danych Dokumentacja poinstalacyjna [Opracowana] powstał w wyniku realizacji zadania Opracowanie dokumentacji przeprowadzonych prac, a następnie ten sam obiekt danych wykorzystano w zadaniu Dostarczenie dokumentacji. W niektórych przypadkach, dla uniknięcia wielokrotnego powtarzania symboli odczytywania/zapisu danych, w modelach BPMN stosuje się uproszczenie polegające na połączeniu obiektu danych z konektorem łączącym czynności procesowe - przykładowo na rysunku 1 obiekt danych Dokumentacja usunięcia usterki jest skojarzony z przepływem sekwencyjnym łączącym zadania, a nie z samymi zadaniami procesowymi.

W przypadku modelowania procesów biznesowych i obiektów danych może się zdarzyć, że scenariusz przepływu procesu za punktem decyzyjnym będzie uzależniony od stanu dokumentu. Np. na rysunku 1 obiekt danych Dokumentacja może przyjąć stan [Odrzucona] i wówczas proces zrealizuje pętlę w celu poprawy tej dokumentacji. Jeżeli natomiast obiekt Dokumentacja będzie miał stan [Zaakceptowana], to wówczas przepływ procesu podąży w kierunku realizacji działań odbiorowych. W takich sytuacjach diagramy BPMN są wzbogacane o opisy - tzw. InputSets, które dla omawianego przypadku maja następującą postać: InputSet1 = {Dokumentacja [Odrzucona]}, InputSet2 = {Dokumentacja [Zaakceptowana]}.

Notacja BPMN dopuszcza umieszczanie na diagramach procesów biznesowych tzw. kolekcji danych (Data Object Collections), które należy interpretować jako zbiór obiektów danych. Czynność przetwarzająca dane z kolekcji ma najczęściej charakter wieloinstancyjny - na rysunku 1 kolekcja danych Procedura akceptacyjna zawiera opis zestawu działań, które należy wykonać w celu weryfikacji prac na obiekcie. Te działania można wykonywać równocześnie, dlatego symbol graficzny zadania Testowanie obiektu został uszczegółowiony.

Modelowanie struktury danych z wykorzystaniem profili języka UML

Naturalnym standardem komplementarnym dla notacji BPMN w zakresie modelowania danych jest język UML (Unified Modeling Language). Język UML można uznać za standard de facto analizy i projektowania systemów informatycznych, lecz z założenia standard ten ma charakter uniwersalny i może być efektywnie wykorzystywany także w innych obszarach. Podstawową zaletą UML jako języka umożliwiającego opracowywanie strukturalnych modeli dokumentów (danych) uzupełniających BPMN jest jego popularność, a co za tym idzie - powszechna znajomość notacji i reguł wykorzystania wśród analityków systemowych i osób wdrażających modele danych, co ułatwia odwzorowanie opracowanych modeli w docelowych środowiskach informatycznych. Pozycja rynkowa tego standardu zapewnia jednocześnie praktyczne uniezależnienie od dostawcy narzędzia - większość narzędzi dostępnych na rynku w pierwszej kolejności zapewnia wsparcie UML-owi, a dopiero w dalszej kolejności innym notacjom. Tym samym organizacja opracowująca i usprawniająca modele własnych procesów zyskuje daleko idącą elastyczność podczas selekcji pakietów narzędziowych i minimalizuje ryzyko utraty wsparcia w dłuższym okresie.

Z kolei słabością UML jest fakt, iż należy on do standardów ponadprzeciętnie rozbudowanych i skomplikowanych, a tym samym trudnych w opanowaniu dla osób z kręgów biznesowych, niedysponujących zazwyczaj stosownymi kompetencjami technicznymi. Jednocześnie notacja ta jest niekompatybilna w ujęciu graficznym z BPMN, co rodzi potencjalne problemy interpretacyjne. Tym samym zasadne jest odejście od wykorzystywania pełnej funkcjonalności UML w zakresie modelowania danych i zaprojektowanie profilu UML o najmniejszym możliwym stopniu złożoności pozwalającym na efektywne modelowanie przedmiotowej dziedziny zastosowań, który jednocześnie wykorzystywałby symbolikę bezpośrednio zaczerpniętą z BPMN. Takie „lekkie” podejścia są wykorzystywane także w dyscyplinie analizy i projektowania systemów informatycznych w oparciu o badania użyteczności poszczególnych diagramów UML i ich kategorii modelowania⁶. Profil UML⁷:

• stanowi celowy, właściwy dla danego obszaru zastosowań podzbiór oryginalnego języka UML, tj. wykorzystuje wybrane diagramy oraz kategorie modelowania standardu UML zgodnie z racjonalnymi zasadami ich filtrowania - adaptacji i kastomizacji do docelowego profilu;
• wprowadza nowe pojęcia i kategorie specyficzne dla danego profilu, a tym samym będące poza zakresem samego standardu UML;
• wprowadza ściśle zdefiniowane reguły wykorzystania standardowych bądź dołączanych kategorii modelowania;
• uzupełnia semantykę kategorii modelowania, wyrażoną w języku naturalnym;
• porządkuje i strukturyzuje architekturę języka stanowiącego dany profil.

Na potrzeby specyfikacji strukturalnych zależności pomiędzy dokumentami wykorzystywanymi m.in. w procesie akceptacji prac na obiekcie telekomunikacyjnym posłużono się autorskim profilem UML, przywoływanym w dalszej części niniejszego artykułu pod nazwą BPMNDoc (rysunek 2).

Rysunek 2. Profil UML na potrzeby modelowania danych BPMN - BPMNDoc

Źródło: opracowanie własne.

Profil BPMNDoc opracowano z wykorzystaniem diagramu profili UML, dedykowanego formalizowaniu autorskich rozszerzeń tego standardu na potrzeby indywidualnych zastosowań. Wykorzystuje on metaklasy, zdefiniowane w dokumentacji języka UML⁸ - Class, Package, Association oraz Nesting - wraz z ich domyślnymi atrybutami. Stosownym metaklasom przypisano zaprojektowane stereotypy, ich atrybuty opisowe oraz proponowaną notację zgodnie z konwencją diagramu profili UML.

Proponowany profil ma uniwersalny charakter - z jego wykorzystaniem można opisywać zarówno same dokumenty, jak i dane - stosując konwencje charakterystyczne dla klasy i związku asocjacji wywodzące się bezpośrednio z UML. Mimo iż metamodel notacji BPMN traktuje kolekcję w kategoriach właściwości obiektów danych, w profilu zdecydowano się przypisać niniejszą właściwość pakietowi. Podyktowane jest to elastycznością w zakresie modelowania zbiorów dokumentów, wynikającą z praktycznych doświadczeń - pakiet może grupować zarówno obiekty tego samego typu, jak i obiekty o zróżnicowanej charakterystyce, w szczególności dalsze kolekcje. Pakiety same w sobie mogą mieć przypisane wszystkie charakterystyki obiektu danych, co umożliwia zastosowanie szerokiego zakresu kombinacji notacyjnych wywodzących się bezpośrednio z notacji BPMN, jak również zapewnia kompatybilność graficzną. Choć w globalnym ujęciu danych specyfikowanie takich właściwości, jak wejścia i wyjścia danych, ma znaczenie drugorzędne, stereotypy te uwzględniono w profilu z uwagi na ich użyteczność podczas opracowywania lokalnych, szczegółowych modeli danych dla poszczególnych procesów.

Jako że w ramach modelu danych odmienne traktowanie obiektów danych i referencji do obiektów danych zgodnie z metamodelem BPMN ma ograniczoną wartość dodaną dla analityka biznesowego⁹, nie rozróżniono tych elementów i umożliwiono przypisywanie stanów bezpośrednio obiektom danych. Z uwagi na źródłową charakterystykę klasy UML w modelach dokumentów można dwojako wykorzystywać stereotypy obiektów danych. Stosunkowo proste modele mogą bazować wyłącznie na symbolice obiektu danych i nazwie (por. rys. 3). Z kolei bardziej rozbudowane modele powinny wykorzystywać klasyczną reprezentację klasy z graficznym stereotypem obiektu danych w prawym górnym narożniku, z uwzględnieniem listy właściwości obiektu danych wyszczególnionych jako atrybuty danej klasy.

Zgodnie z metamodelem profilu BPMNDoc składnice danych nie mogą być kolekcjami ani mieć charakteru wejściowego (wynikowego). Zastosowanie autorskiego profilu ilustruje rysunek 3.

Rysunek 3. Struktura dokumentów w procesie akceptacji prac na obiekcie telekomunikacyjnym

Źródło: opracowanie własne.

Jak zaprezentowano na rysunku 3, partner biznesowy odpowiedzialny za realizację Zamówienia wykonania prac jest zobowiązany dostarczyć zleceniodawcy Dokumentację poinstalacyjną. Dokumentacja ta ma charakter kolekcji, której integralnymi częściami są Lista testów wraz z Zestawieniami wyników, Fotografie oraz Rysunki techniczne. Składowe kolekcji zaznaczono na modelu danych z wykorzystaniem związku zagnieżdżenia, będącego jednym z dwóch związków UML ujętych w metamodelu. Z uwagi na fakt, iż w proponowanym rozszerzeniu kolekcje są stereotypowanymi pakietami UML, alternatywnie można zastosować standardową notację pakietu z przypisanym graficznym stereotypem kolekcji, a elementy składowe pakietu umieścić w jego wnętrzu w sposób jawny. Zamówieniu wykonania prac towarzyszą także Wytyczne instalacyjne. Podczas realizacji procesu biznesowego akceptacji prac na obiekcie telekomunikacyjnym opracowywana jest także faktura VAT (FV), która z punktu widzenia modelu danych przypisywana jest każdorazowo do odpowiedniego Zamówienia wykonania prac.

W odróżnieniu od Dokumentacji poinstalacyjnej, Dokumentacja poodbiorowa to kolekcja dokumentów sporządzana we współpracy ze zleceniodawcą. Jej opracowanie wymaga wizji lokalnej w terenie. Integralną częścią tej ostatniej jest Procedura akceptacyjna, do której również dołączane są Zestawienia wyników testów. Oprócz wspomnianych elementów Dokumentacja poodbiorowa ujmuje Protokół inspekcji technicznej wraz z ewentualnymi Fotografiami dokumentującymi stan faktyczny. W kolejnych iteracjach prac osiąga się poziom jakości umożliwiający wystawienie Certyfikatu odbioru, który należy traktować jako zaświadczenie dla wykonawcy zlecenia. Ewentualne pomniejsze usterki są usuwane na późniejszym etapie, a w Dokumentacji usunięcia usterki uwzględnia się każdorazowo numer uprzednio wydanego Certyfikatu odbioru.

Wynagrodzenie za wykonaną pracę znajduje odzwierciedlenie w zmodyfikowanym statusie faktury oraz osobnym dokumencie - Płatność. Z uwagi na fakt, iż kwota umowna może być wypłacana w transzach, wyspecyfikowano liczebność związku z FV po stronie Płatności jako 1..* .

Modele dokumentów i danych BPMS jako notacja wspomagająca BPMN

Inną potencjalną notacją komplementarną w stosunku do BPMN 2.0 w zakresie modelowania danych jest BPMS. Notacja ta została opracowana przez D. Karagiannisa z Uniwersytetu Wiedeńskiego. Następnie, przy współpracy z firmą BOC, notacja BPMS została zaimplementowana w środowisku ADONIS, które jest narzędziem do projektowania, symulacji i analizy procesów biznesowych. W notacji BPMS definicja procesu biznesowego może mieć postać wielowymiarową. Podstawowym elementem takiej kompleksowej definicji procesu jest model procesu biznesowego, który - podobnie jak diagram BPMN - obrazuje początek procesu, następnie czynności, punkty decyzyjne, przepływy równoległe i możliwe zakończenia przepływu pracy. Wielowymiarowość definicji polega na tym, że podstawowy model procesu biznesowego jest uzupełniany o kolejne typy modeli, których wykorzystanie w komplecie nie jest obligatoryjne, jednakże podnosi wartość i stopień zrozumienia tworzonego projektu. Do najchętniej używanych typów należą modele: środowiska pracy, systemów IT, ryzyk i kontroli ryzyk, a także modele produktów, zasobów, dokumentów i danych. Dwa ostatnie pozwalają spojrzeć na zagadnienie „danych w procesach biznesowych” na dwa sposoby:

• pod kątem dokumentów wykorzystywanych w trakcie realizacji procesu biznesowego,
• pod kątem zestawów atrybutów, które są skojarzone z czynnościami procesowymi.

Dokumenty w procesie biznesowym to zbiór formularzy, instrukcji, wzorów pism, przepisów itp., które są wykorzystywane przez uczestników procesów do realizacji czynności. Model dokumentów w notacji BPMS rozpoczyna się od zaprojektowania zbioru ikonek reprezentujących dokumenty w procesie. Rysując taki model w narzędziu ADONIS, można dodatkowo skojarzyć symbol dokumentu z konkretnym dokumentem, który znajduje się na obszarze dyskowym dostępnym dla projektanta. Opisane symbole dokumentów można pogrupować w obszary wskazujące na to, kto ma dostęp do dokumentów i kto z nich korzysta. Tak opracowany model należy skojarzyć z podstawową definicją procesu, tzn. przypisać dokumenty do czynności procesowych. Dokumenty można ponadto rozpatrywać precyzyjniej jako zasób wejściowy dla czynności procesowej, np. formularz, a także jako zasób wyjściowy, np. formularz uzupełniony o dane klienta.

Jeśli model procesu biznesowego ma zostać zaimplementowany w systemie workflow, wymagany element projektu systemu stanowi relacyjna baza danych. Model danych BPMS w środowisku ADONIS nie jest wyczerpującym projektem takiej bazy danych, jednakże pozwala projektantowi modelu procesu biznesowego w użyteczny sposób przekazać projektantom bazy informacje o tym, jakie dane są skojarzone z poszczególnymi etapami procesu. Notacja BPMS umożliwia opracowanie podstawowych tabel oraz umieszczenie w nich atrybutów włącznie ze wskazaniem ich typów. Dodatkowo, w tabelach można zamieścić klucze główne i obce, jednakże opracowanie relacji wykracza poza funkcjonalności systemu ADONIS i wymaga skorzystania z dedykowanych narzędzi do projektowania baz danych.

Podsumowanie

Poruszona w niniejszym artykule kwestia zasadności rozszerzania modeli procesów biznesowych o wymiary danych i dokumentów ma charakter zarówno akademicki, jak i praktyczny. Przedstawione notacje komplementarne stają się użyteczne już w momencie, gdy projektowane modele procesów wymagają uszczegółowienia o niskopoziomowe informacje - których scharakteryzowanie wyłącznie w sposób opisowy jest nieprecyzyjne i niewystarczające. Zunifikowane modele dokumentów i danych mają natomiast szczególne znaczenie na poziomie automatyzacji procesów biznesowych, które po implementacji na silnikach tych procesów wspierają nie tylko obieg pracy, ale także wymianę informacji bazujących na procesowanych danych i dokumentach. Mocną stroną przedstawionego na rysunku 1 rozwiązania hybrydowego, zaproponowanego przez twórców BPMN, jest jasne powiązanie danych z czynnościami procesowymi. Naniesiona dodatkowo informacja dotycząca stanów dokumentów jeszcze precyzyjniej opisuje sposób przetwarzania tychże. Wadą połączenia modelu stricte procesowego BPMN z dokumentami jest ewidentne zmniejszenie czytelności diagramu, co jednocześnie znacznie redukuje liczbę potencjalnych jego odbiorców. Tej wady nie posiadają ani profil UML-owy BPMNDoc, ani dedykowane diagramy ADONIS-owej notacji BPMS, które pozostają czytelne dla analityków zarówno biznesowych, jak i systemowych, wskazując jednocześnie związki pomiędzy dokumentami. Jednakże w tym przypadku następuje odseparowanie danych szczegółowych od dynamiki procesu, co wymaga analizowania wielu modeli w celu uchwycenia związku pomiędzy czynnościami procesowymi a dokumentami. Obie potencjalne notacje komplementarne posiadają określone przewagi oraz słabe strony w stosunku do swojego konkurenta. Syntetyczne porównanie alternatywnych podejść ujęto w tabeli 2.

Niezależnie od sposobu prezentacji dokumentów i danych prezentowany obszar tematyczny wymaga dalszej eksploracji uwzględniającej realne, biznesowe scenariusze. Jedną z przesłanek stanowi fakt, że z czynnością procesową może być skojarzonych wiele dokumentów o zsynchronizowanych stanach - przykładowo wysłanie towaru do klienta może angażować dokument Faktura w stanie [Zapłacona], a także dokumenty: Gwarancja [Wypełniona] oraz Kupon_Promocyjny [Aktywowany]. Drugim interesującym scenariuszem jest sytuacja, w której obiekt danych może stanowić złożony wyzwalacz realizacji czynności procesowych, tzn. określone zadanie zostanie zrealizowane wyłącznie wtedy, gdy dane potrzebne do jego wykonania są dostępne i cechuje je dodatkowo odpowiedni stan (stany). Ma to zastosowanie w przepływach równoległych, w których nieumiejętny rozkład danych może spowodować tzw. zakleszczenie (np. klient zapłaci za towar tylko wówczas, gdy taki towar otrzyma, natomiast hurtownia wyśle towar tylko wtedy, gdy zaksięguje wpłatę). Kolejnym elementem, który warto zunifikować na etapie projektowania procesów, jest zapisywanie (odczytywanie) danych z elektronicznych repozytoriów. Może się bowiem zdarzyć, że czynności zorganizowane w wątki równoległe odczytują dane ze wspólnego obiektu danych lub zapisują je we wspólnym obiekcie. Notacje BPMN, UML i BPMS nie posiadają mechanizmów regulujących synchronizację przetwarzania obiektu danych. Ciężar opracowania synchronizacji zostaje często przeniesiony bezpośrednio na twórców systemu informatycznego, co przy ich nieznajomości domeny biznesowej może być źródłem problemów.

Bibliografia

• R.S. Aguilar-Saven, Business Process Modelling: Review and Framework, „International Journal of Production Economics” 2004, No. 90, s. 129-149.
• Business Process Model and Notation (BPMN). Version 2.0.2, Object Management Group, 2013, http://www.omg.org/spec/BPMN/2.0.2/.
• Business Process Reengineering and Beyond, International Technical Support Oganization, IBM, 2013 http://www.redbooks.ibm.com/redbooks/pdfs/sg242590.pdf.
• H. Chestnut, Systems Engineering Methods, Wiley, 1967.
• B. Dobing, J. Parsons, How UML is Used, „Communications of ACM” 2006, Vol. 49, No. 5, s. 109-113.
• T. Dufresne, J. Martin, Process Modeling for E-Business, INFS 770 Methods for Information Systems Engineering: Knowledge Management and E-Business, 2003.
• H. Eriksson, M. Penker, Business Modeling with UML: Business Patterns at Work, Wiley, 2000.
• B. Gawin, B. Marcinkowski, Symulacja procesów biznesowych. Standardy BPMS i BPMN w praktyce, Helion, Gliwice 2013.
• W. Hongli, Y. Baolin, Z. Xia, X. Gang, Data Description and Data Access Mechanism in Distributed Workflow System, Beihang University, 2007.
• Information technology - Object Management Group Unified Modeling Language (OMG UML) - Part 2: Superstructure (ISO/IEC 19505-2:2012). Version 2.4.1, 2012, http://www.omg.org/spec/UML/ISO/19505-2/PDF/.
• ISO 5807:1985. Information processing - Documentation symbols and conventions for data, program and system flowcharts, program network charts and system resources charts, 1985, http://www.iso.org/iso/iso_catalogue/ catalogue_tc/catalogue_detail.htm?csnumber=11955.
• S. Johnston, Rational UML Profile for Business Modeling, 2004, http://www.ibm.com/developerworks/rational/library/5167.html.
• A. Kalnins, D. Kalnina, A. Kalis, Comparison of Tools and Languages for Business Process Reengineering, [w:] D.H. Withers, R.N. Zobel (eds.), Proceedings of the Third International Baltic Workshop on Databases and Information Systems; IEEE Computer Society, 1998.
• D. Karagiannis, S. Junginger, R. Strobl, Introduction to Business Process Management System Concepts, [w:] B. Scholz-Reiter, E. Stickel (eds.), Business Process Modelling; Springer-Verlag, 1996.
• W. Kowalczewski, J. Nazarka (red.), Instrumenty zarządzania współczesnym przedsiębiorstwem, Difin, Warszawa 2006.
• J. Krogstie, Using EEML for Combined Goal and Process Oriented Modeling: A Case Study, [w:] T. Halpin, J. Krogstie, E. Proper (eds.), Proceedings of EMMSAD'08. Thirteenth International Workshop on Exploring Modeling Methods for Systems Analysis and Design, Montpellier 2008.
• R.J. Mayer et al., Information Integration for Concurrent Engineering (IICE) IDEF3 Process Description Capture Method Report, 1995, http://www.idef.com/pdf/Idef3_fn.pdf.
• M. Odeh, I. Beeson, S. Green, J. Sa, Modelling Processes Using RAD and UML Activity Diagrams: an Exploratory Study, 2002, http://www.cems.uwe.ac.uk/~sjgreen/RAD&AD_V2.pdf.
• C.A. Petri, Kommunikation mit Automaten; Universität Bonn, 1962.
• S. Sadiq, M. Orlowska, W. Sadiq, C. Foulger; Data Flow and Validation in Workflow Modelling, University of Queensland, 2004.
• A.W. Scheer, Architecture of Integrated Information Systems, Springer-Verlag, 2002.
• S. Wrycza, B. Marcinkowski, UML 2 Academic Course - Methodological Background and Survey Benchmarking, [w:] Proceedings of the 23rd Annual Conference for Information Systems Educators. Volume 23, AITP Foundation for Information Technology Education, 2006.
• S. Wrycza, B. Marcinkowski, J. Maślankowski, UML 2.x. Ćwiczenia zaawansowane, Helion, Gliwice 2012.
• E. Yourdon, Współczesna analiza strukturalna, Wydawnictwa Naukowo-Techniczne, Warszawa 1996.