PROCESY W FIRMIE PROCESY W FIRMIE

BPMN UNIWERSALNYM
Oczywiście
wyniki alokacji JĘZYKIEM BIZNESU:
OGÓLNE SPOJRZENIE NA MODEL
mogą być
widoczne nie tylko
w pod­sumowaniu
alokacji.

Jedną z najważniejszych kwestii we współczesnym świecie biznesu jest komunikacja.

Zapewnienie odpowiedniej przejrzystości przekazu jest zatem kluczowe. Autorzy serii
publikacji chcą pokazać czytelnikowi, jak notacja Business Process Modeling Notation
(BPMN) spełnia ten warunek. Użyteczność tej metody zapisu przebiegu procesów
Rysunek 8. Podsumowanie alokacji typu distribution [Źródło: opracowanie własne]
rośnie wraz z wykorzystaniem narzędzi informatycznych.

N
iniejszy artykuł jest pierwszym w serii przybliżającym
TYTUŁ: BPMN uniwersalnym językiem biznesu: ogólne spojrzenie
zapis rzeczywistości biznesowej, który pozwala nie tylko na model

w sposób czytelny i łatwy do zrozumienia ją przedstawić DZIAŁ: PROCESY W FIRMIE

Rysunek 9. Wynik końcowy alokacji typu assessment [Źródło: opracowanie własne]
pozwalające zobrazować pierwotne wartości przed alokacją, jako
że ta alokacja w przeciwieństwie do metody Assessment zeruje
każde pojedyncze konto i przenosi koszty na właściwe centra w ob-
rębie tych samych kont. Pozwala to co prawda zachować właściwą
strukturę kosztową na działach obciążonych kosztami, ale utrudnia
analizę kosztów na departamentach wspierających.
Jako alternatywę dla powyższej metody pokażemy też
wynik końcowy alokacji typu assessment, gdzie ciągle wi-
doczne są koszty pod tzw. Primary cost elements, a cała alokacja
dokonywana jest tylko na kilku tzw. Secondary cost elements
(Rysunek 9).
Pozwala to na uzyskanie większej przejrzystości w analizach
przepływów kosztów między działami, bez tracenia przy oka-
zji struktury kosztowej w działach wspierających. Wadą takiego
rozwiązania jest za to zaburzenie struktury kosztowej w działach
przyjmujących koszty.
Oczywiście powyższe przykłady nie wyczerpują całej tematyki
tworzenia cykli alokacyjnych i poszczególnych segmentów w ich
ramach, ale pozwalają wyrobić sobie pogląd, że nie jest to za-
nadto skomplikowane, a może znacznie ułatwić pracę w czasie
zamknięć miesiąca, a także zwiększyć transparentność i ponie-
kąd odczarować często kontrowersyjny temat alokacji w wielu
przedsiębiorstwach.
Nie mówiąc już o oszczędności czasu i uniknięciu po-
myłek przy dokonywaniu ręcznych alokacji w Excelu, co
wciąż, niestety, nie jest rzadką praktyką, a co gorsza spotykaną
nawet w firmach używających SAP jako swój system ERP.
odbiorcy, ale przy okazji daje możliwość analizy poprzez symula-
cję. Autorzy od samego początku będą podkreślać tę możliwość,
gdyż wyróżnia się ona znacząco na tle pozostałych celów, jakie
osiąga się przez takie działania. Do tych pozostałych – oczywi-
stych – należą dokumentacja procesów, źródło informacji dla
pracowników o sposobie wykonania zadań, sposób informowa-
nia interesariuszy zewnętrznych o przebiegu procesów ich ob-
sługi, elementarz dla nowo przyjmowanych pracowników.
Punktem wyjścia do przedstawienia wspomnianych zagadnień
będzie model procesu analizy jakości syropu w wiodącym kon-
cernie farmaceutycznym. Proces ten będzie tłem dla całego cyklu
artykułów wprowadzających do tematyki modelowania. Autorzy
długo wahali się, czy prezentować idee i techniki związane z mo-
delowaniem procesów w notacji BPMN ver. 2 na konkretnym
case study, czy może próbować to zobrazować na abstrakcyjnym
przykładzie. Jednak za wyborem tego pierwszego sposobu, czy-
li zastosowania konkretnego nazwanego procesu dotyczącego
Rysunek 1. Model procesu analizy jakościowej leku [Źródło: opracowanie własne za pomocą iGrafx Process for Six Sigma]
AUTOR: dr Bartosz Banduła, dr inż. Tomasz Wojdyński – Wydział
Zarządzania, Finansów i Informatyki, Wyższa Szkoła Zarządzania
i Bankowości w Krakowie
Jedną z najważniejszych kwestii współczesnego świata biznesu jest komunikacja. Zapewnienie
odpowiedniej przejrzystości przekazu jest zatem kluczowe. Autorzy serii publikacji chcą pokazać
czytelnikowi jak notacja Business Process Modeling Notation (BPMN) spełnia ten warunek.
Użyteczność tej metody zapisu przebiegu procesów rośnie wraz z wykorzystaniem narzędzi
informatycznych.
określonej sytuacji, przemawia łatwość zrozumienia. Czytelniko-
wi zaś autorzy pozostawiają próbę przełożenia przedstawianych
zagadnień na swoją praktykę.
Przedstawienie modelowanego procesu
Proces dotyczy analizy jakościowej leku w postaci syropu
w laboratorium chemicznym i przebiega następująco: do
laboratorium przychodzi próbka leku, którą należy zbadać pod
kątem zachowania parametrów jakościowych. Próbka trafia do
pokoju przyjmowania prób, gdzie jest rejestrowana. Jeżeli jest

26 INFORMACJA ZARZĄDCZA 8/2017 8/2017 INFORMACJA ZARZĄDCZA 27

 PROCESY W FIRMIE PROCESY W FIRMIE

Początek modelu
procesu, któ­ry
Dalszy fragment przebiegu
zawiera opis
pro­cesu, w którym pojawia się
organizacji,
miejsce podejmowania decyzji.
w której proces
się odbywa.

Rysunek 2. Powiększona część pierwsza przebiegu procesu [Źródło: opracowanie własne za pomocą iGrafx Process for Six Sigma] Rysunek 3. Powiększona część druga przebiegu procesu [Źródło: opracowanie własne za pomocą iGrafx Process for Six Sigma]

próbką „normalną”, jest rejestrowana w systemie ewidencyjnym.
Jeżeli jest to próba „walidacyjna”, to jest rejestrowana poprzez
zeszyt prób.
Po zarejestrowaniu trafia ona do dedykowanej szafy. Następnie
analityk przychodzi, aby ją pobrać – fakt poboru próby jest re-
jestrowany (w zależności od tego, czy próbka jest normalna czy
walidacyjna – w systemie rejestrowym lub zeszycie).
Próbka przenoszona jest na stanowisko laboratoryjne, gdzie
dokonywana jest analiza. Polega na jednoczesnym wykonaniu
czynności przez trzech różnych analityków:
„„ analizy klasycznej1,
„„ analizy zawartości substancji czynnej,
„„ oznaczenia zawartości alkoholu etylowego.
Każdy z analityków na końcu swojego procesu dokonuje oceny
uzyskanego wyniku.
Po zakończeniu trzyetapowej analizy następuje weryfikacja da-
nych. Jeśli wyniki trzech analiz są pozytywne, to ta informacja wpi-
sywana jest do systemu rejestrowego, a produkt, którego dotyczy
próbka, może być przekazany do dystrybucji. Jeśli którakolwiek
część analizy dała rezultat negatywny, to rozpoczyna się docho-
dzenie laboratoryjne. W takim przypadku w pierwszej kolejności
sprawdzane jest, czy analityk zgłaszający wynik negatywny nie
popełnił błędu obliczeniowego. Jeśli wykryto błąd w jego oblicze-
niach, to jest on korygowany, a produkt kierowany do dystrybucji.
Jeśli nie wykryto błędu obliczeniowego, to weryfikacji podlega
całość analizy poprzez powtórzenie całego procesu badania. Je-
żeli wynik nadal jest negatywny, oznacza to złą jakość produktu
i dyskwalifikację całej serii z procesu dystrybucji. Jeśli wynik jest
pozytywny, to partia produktu jest przekazywana do dystrybucji.
1
Dokładny opis wykonywanych czynności nie jest dla potrzeb tych rozważań istot-
ny, więc zostanie pominięty, aby zachować przejrzystość wywodu.
Powyższy opis procesu biznesowego zostanie teraz przed-
stawiony na modelu wykonanym w notacji BPMN ver. 2.
Czytelnik zatem będzie mógł od razu zweryfikować pod swoim
kątem powszechną opinię, że rysunek jest wart więcej niż tysiąc
słów.
Nie wdając się na razie w szczegóły implementacji samej notacji
BPMN ver. 2, przeanalizujemy ten schemat fragmentami – zwięk-
szając je w celu poprawienia czytelności jego poszczególnych
elementów. Do elementów tych zaliczamy zdarzenia, linie łączą-
ce oznaczające przepływ pracy, czynności, miejsca podejmowa-
nia decyzji lub rozgałęzień procesu (bramki) oraz uzupełniające
informacje dodatkowe (artefakty).
Na Rysunku 2 przedstawiono początek modelu procesu, który
zawiera opis organizacji, w której proces się odbywa, zwanej
w BPMN basenem – napis „Firma farmaceutyczna”. Kolejno wska-
zany jest dział, w którym zachodzi proces – napis „Laboratorium”.
W nomenklaturze standardu nazywany jest torem. Cały proces
rozpoczyna zdarzenie początkowe, które oznaczone jest kół-
kiem (1), po którym następują wykonywane czynności (2 i 3)
połączone liniami wskazującymi przebieg procesu. Dodatkowo
przebieg procesu oznaczony jest kierunkiem strzałek kończą-
cych linię przebiegu procesu. Numery użyte w opisie to funkcjo-
nalność samego oprogramowania iGrafx for Six Sigma i pomimo
niezachowanej kolejności zostaną przez autorów wykorzystane
w opisie.
Lakoniczny opis poszczególnych elementów jest spowodowany
faktem, że będą one szczegółowo omówione w kolejnych czę-
ściach cyklu artykułów.
Kolejny rysunek 3 przedstawia dalszy fragment przebiegu proce-
su, w którym pojawia się miejsce podejmowania decyzji. Nastę-
puje tutaj rozwidlenie przebiegu procesu, a realizowane jest to za
Rysunek 4. Powiększona część trzecia przebiegu procesu [Źródło: opracowanie własne za pomocą iGrafx Process for Six Sigma]
pomocą tzw. bramki logicznej „Albo” (oznaczona numerem 4 na
rysunku). Jeśli seria jest „normalna”, przebieg zostanie skierowany
do czynności oznaczonej numerem 5, tj. Rejestracja w SAP; w przy-
padku gdy seria jest „walidacyjna”, przebieg przechodzi do czyn-
ności oznaczonej numerem 6, tj. Rejestracji w zeszycie. Kolejnym
etapem na obu ścieżkach przejścia jest bramka scalająca „Albo”
oznaczona numerem 13, po przejściu której proces przechodzi do
czynności oznaczonej numerem 14 – Próbka trafia do szafy.
Z czynności 14 – Próbka trafia do szafy – następuje przejście
do czynności numer 15 – Pobranie próbki z szafy i rejestracja,
kolejno do czynności Przeniesienie próbki na stanowisko labo-
ratoryjne (numer 16), a następnie do czynności Przygotowanie
do analizy (numer 40). Korzystając z okazji, że fragment ten jest
najmniej skomplikowany, dodamy kolejną informację, która do-
tychczas nie była uwzględniona w tekście artykułu, a widocz-
Artefakty, czyli informacje
dodatkowe – tutaj zawierające
czasy trwania poszczególnych
czynności.
na jest na modelu; są to artefakty, czyli informacje dodatkowe
– tutaj zawierające czasy trwania poszczególnych czynności. Ich
zastosowanie i sposób tworzenia będą omówione w kolejnych
odcinkach omawiania metody modelowania.
Ten fragment jest najbardziej skomplikowaną częścią
omawianego procesu, ale dowodzi on jednocześnie, że
modelowaniu mogą podlegać również złożone rozwiązania. Po
zakończeniu czynności Przygotowanie do analizy (40) proces
przechodzi do bramki rozdzielającej Lub (46). Nazwa może być
myląca dla czytelnika, a więc należy zwrócić uwagę, że w tym
miejscu proces zostaje rozdzielony równocześnie na trzy przebie-
gi dziejące się równolegle:
Analizę klasyczną (24),
Analizę zawartości substancji czynnej (26),
Analizę zawartości etanolu (25).

28 INFORMACJA ZARZĄDCZA 8/2017 8/2017 INFORMACJA ZARZĄDCZA 29

 PROCESY W FIRMIE PROCESY W FIRMIE

Rysunek 5. Powiększona część czwarta przebiegu procesu [Źródło: opracowanie własne za pomocą iGrafx Process for Six Sigma]
Takie rozdzielenie jest sensowne ze względu na to, że każda
z tych czynności wykonywana jest przez inną osobę, a zatem
dzieje się równolegle. Gdyby sobie wyobrazić, że wykonuje je
jedna i ta sama osoba, to przebieg oczywiście wyglądałby ina-
czej. Cechą charakterystyczną bramki rozdzielającej „Lub”, nie
wdając się w szczegóły, jest to, że przebieg nią otwarty zamykany
jest bramką scalającą „Lub” (47). Jak widać na Rysunku 5, czasy
trwania poszczególnych czynności są różne, zatem zakończą się
one w różnym momencie. Jednak proces będzie czekał na za-
ROBOT
W SŁUŻBIE WYDAJNOŚCI
Czy można radykalnie skrócić czas reagowania przez IT na ciągle pojawiające
się potrzeby usprawnienia pracy z aplikacjami biznesowymi? Współczesne
przedsiębiorstwa szeroko korzystają z możliwości systemów informatycznych
Excel narzedzia wspomagających rejestrację, przetwarzanie i udostępnienie danych biznesowych.
Po okresie mozolnego budowania aplikacji realizujących wybrane funkcjonalności
Menedżer nazw
(obsługa kartoteki magazynowej, rozliczenia płacowe, fakturowanie itp.) obecnie
Narzędzie do tworzenia, edytowania, usuwania i znajdo- można mówić o braku ograniczeń technologicznych w biznesowych zastosowaniach
wania wszystkich nazw w skoroszycie. informatyki.

kończenie wszystkich trzech czynności i przejście do następnej
czynności z bramki scalającej „Lub” (47) do czynności Weryfikacja
wyniku (31) nastąpi po zakończeniu czynności 25 i 26.
Z czynności 31 proces przechodzi do bramki decyzyjnej „Albo”
(32), identycznej z elementem 4 omawianym wyżej. Jeśli badanie
zakończyło się pomyślnie, to znaczy wszystkie typy analiz (24, 25,
26) zakończyły się sukcesem, to następuje przejście do wykona-
nia czynności 33, tj. Wpisanie do SAP i zwolnienie produktu. Stąd
krótka droga do zdarzenia 35, tj. zakończenia przebiegu procesu.
Jeśli jednak którakolwiek z analiz (24, 25, 26) zakończy się nega-
tywnie w bramce 32, proces przechodzi do czynności 34 – Do-
chodzenie laboratoryjne. Po jego zakończeniu, jak widać na rysun-
ku (artefakt), trwa ono 30 minut, następuje przejście do kolejnej
bramki decyzyjnej „Albo”, w której zadaje się pytanie, czy nastąpił
błąd analityka. Jeśli błędu nie stwierdzono, proces przechodzi do
czynności Produkt złej jakości – dyskwalifikacja serii (41), a następ-
nie do zdarzenia 42, tj. zakończenia przebiegu procesu.
Jeśli stwierdzono wystąpienie błędu spowodowanego przez anali-
tyka (któregokolwiek), to proces wraca do czynności 40 i następuje
ponowny przebieg. Teoretycznie rozważając, można zauważyć, że
taki proces może się nigdy nie skończyć. Jednak w kolejnych arty-
kułach, w których uwzględnimy dodatkowe parametry, takie jak
statystyki czynności, zobaczymy, że taka sytuacja jest praktycznie
niemożliwa.
Założeniem wstępnym artykułu było zapoznanie czytelnika
z ideą modelowania procesu biznesowego w notacji BPMN ver.
2 w celach informacyjnych i dokumentacyjnych. Jednak autorzy
zwracają uwagę, że jest to dopiero początek działań i jedna z naj-
ważniejszych rzeczy – ich zdaniem – symulacja przebiegu pro-
cesu i wynikające z niej wielkości liczbowe (czas trwania, zużycie
zasobów, kolejka) – będzie zamykała serię artykułów. Już po tym
wstępnym artykule można zauważyć, że pomimo prostoty stwo-
rzonego modelu potrzebna jest znajomość przynajmniej niektó-
rych jego fragmentów, np. element 46 – bramka rozdzielająca
„Lub”. Zachęcamy więc do lektury kolejnych publikacji z tej serii.
Na portalu:
BPMN – Business Process Model
and Notation
N
iestety, konsekwencją takiej historii rozwoju jest fakt, że
w wielu organizacjach do obsługi informatycznej pro-
cesu przetwarzania i dostarczania informacji zarządczej
wykorzystuje się wiele różnych aplikacji, które nie były projekto-
wane do współpracy ze sobą. Dziś zaś potrzebne jest pozyskiwa-
nie spójnej informacji z tych systemów. Najczęściej osiąga się to
dzięki pracownikom, którzy lepiej lub gorzej potrafią realizować
swoje zadania, przełączając się pomiędzy wieloma niepowią-
zanymi aplikacjami biznesowymi. Zazwyczaj dane są ostatecz-
nie scalane w arkuszu kalkulacyjnym. Dzieje się tak nawet, gdy
przedsiębiorstwa posługują się oprogramowaniem o dużej zło-
żoności (MRP II/ERP) – mimo to wtedy często nadal eksploatują
inne, uzupełniające oprogramowanie, bo dostarcza możliwości,
których nie mają główne systemy.
Zanim informacja zarządcza stanie się podstawą do podjęcia de-
cyzji, zwykle przechodzi dłuższą lub krótszą drogę przetwarzania.
Proste dane pierwotne są interesujące dla menedżera/decyden-
tów tylko w niewielkim zakresie. Zwykle oczekują oni danych
przetworzonych, które zostały poddane różnym procesom. Im
bardziej złożony jest proces przetwarzania, im więcej operacji
z wykorzystaniem różnych systemów informatycznych jest wy-
konywanych na danych, tym później uzyskujemy efekt i tym bar-
dziej wzrasta ryzyko błędów.
Większość współczesnych przedsiębiorstw wyposażonych jest
w różnego rodzaju oprogramowanie biznesowe. Wiele z nich
przekonało się, że wdrożenie nawet najbardziej rozbudowane-
go funkcjonalnie systemu zintegrowanego wcale nie zaspokaja
wszystkich potrzeb informacyjnych i operacyjnych. Ciągle poja-
TYTUŁ: Robot w służbie wydajności
DZIAŁ: PROCESY W FIRMIE
AUTOR: Danuta Kajrunajtys – analityk biznesowy, First Byte sp. z o.o.
Czy można radykalnie skrócić czas reagowania przez IT na ciągle po-
jawiające się potrzeby usprawnienia pracy z aplikacjami biznesowy-
mi? Współczesne przedsiębiorstwa szeroko korzystają z możliwości
systemów informatycznych wspomagających rejestrację, przetwarzanie i udostępnienie danych
biznesowych. Po okresie mozolnego budowania aplikacji realizujących wybrane funkcjonalności
(obsługa kartoteki magazynowej, rozliczenia płacowe, fakturowanie itp.) obecnie można mówić
o braku ograniczeń technologicznych w biznesowych zastosowaniach informatyki.
wiają się nowe, specyficzne potrzeby. Dzieje się to szybciej, niż
własne IT jest w stanie dostarczyć usług zaspokajających te po-
trzeby. Oczywiście, IT różnymi metodami próbuje tym zarządzać,
ale często jest to jak przyklejanie plasterka na złamaną kończynę.
Jakiej informacji zarządczej potrzebują
menedżerowie?
Finalna informacja zarządcza przechodzi obróbkę od
etapu uchwycenia danych pierwotnych. To przebieg pro-
cesu biznesowego i potrzeby zarządcze menedżerów określają,
kiedy, w jaki sposób oraz jakie czynności związane z informacją
powinny zostać wykonane. Czynności te wykonywane są na po-
szczególnych stanowiskach pracy z wykorzystaniem aplikacji
biznesowych.
Aby informacja zarządcza była użyteczna na potrzeby podejmo-
wania decyzji, musi być:
„„ DOSTĘPNA – we właściwym czasie i formie – jeśli informacje
są gromadzone i przechowywane w różnych systemach in-
formatycznych, a także poza nimi (ewidencja papierowa), to

30 INFORMACJA ZARZĄDCZA 8/2017 8/2017 INFORMACJA ZARZĄDCZA 31