Modelowanie procesów - Metodologia prof. Scheera

Na stworzonej przez niego koncepcji oparte jest jedno z wiodących narzędzi, służących mapowaniu i reorganizacji procesów – pakiet programów ARIS. Podstawy swojej metodologii prof. Scheer zawarł w książce Architektur Intergrieter Inforamtionssysteme, wydanej w 1991 roku. Koncepcja stworzona przez prof. Scheera i zaimplementowana w ARISie zakłada, że model procesów może być przedstawiony w czterech perspektywach:

-organizacji (organization view), w której ukazane są elementy struktury organizacyjnej organizacji
-danych (data view), przedstawiająca system informacyjny organizacji
-funkcji (function view), ukazująca występujące w procesie funkcje i powiązania między nimi
-sterowania (control view), łącząca wydarzenia, funkcje i wszystkie pozostałe elementy występujące w poprzednich trzech perspektywach; umożliwia na przedstawienie wzajemnych powiązań pomiędzy pozostałymi perspektywami.

W ramach każdej z czterech perspektyw wyróżnić można trzy poziomy (descriptive levels) opisujące przejście od problemu biznesowego do technologii informacyjnej:

1. zdefiniowanie wymagań (requirements definition) – na poziomie tym określa się wymagania dla technologii informacyjnych
2. specyfikacja projektowa (design specification) – na tym poziomie powstaje specyfikacja systemu informacyjnego, który spełni postawione na pierwszym poziomie wymagania
3. opis implementacji (implementation description) – w ramach tego poziomu specyfikacja przekształcana jest we wdrożenie odpowiedniego sprzętu komputerowego i oprogramowania

Z punktu widzenia modelującego i przekształcającego proces analityka najważniejszy jest pierwszy poziom – czyli zdefiniowanie wymagań dla systemu informacyjnego.

Metodologia prof. Scheera wyróżnia jeszcze jedną perspektywę – zasobów informacyjnych (resource view), która zawarta jest w poziomach specyfikacji projektowej (design specification) i implementacji (implementation description), i przez to nie występuje jako osobna perspektywa, tak jak pozostałe cztery wcześniej przedstawione perspektywy.

Modele w ARISie zbudowane są z obiektów i powiązań między nimi. Zarówno obiektom, jak i powiązaniom, przypisany jest zestaw atrybutów, zależny od typu obiektu lub powiązania. Ponieważ dane obiektów przechowywane są w bazie danych wspólnej dla wszystkich modeli, jeden obiekt występować może w wielu modelach. ARIS daje również możliwość tworzenia modelu przez wielu użytkowników równocześnie w architekturze klient-serwer. Poprzez rozbudowany system uprawnień administrator umożliwić może wprowadzanie danych jedynie w tym obszarze, za który dany użytkownik jest odpowiedzialny.

Perspektywa organizacji

W perspektywie organizacji w statyczny sposób przedstawione są elementy struktury organizacyjnej organizacji oraz występujące między nimi relacje. Występuje tu jeden typ modelu – schemat organizacyjny. W schemacie tym elementy struktury organizacyjnej przedstawione są za pomocą typów obiektów przedstawionych na rysunku powyżej. Jednostka organizacyjna (organizational unit) przedstawia funkcjonujące w ramach organizacji jednostki, takie jak dział produkcji, dział planowania. Osoba wewnętrzna symbolizuje konkretnego pracownika firmy (najczęściej wymienionego z imienia i nazwiska), zewnętrzna osobę z zewnątrz- na przykład konsultanta. Stanowisko (position), które jest najmniejszą jednostką organizacyjną w firmie, oznacza zajmowaną przez pojedynczego pracownika pozycję (np. kierownik produkcji, asystent zarządu).

Typowy schemat organizacyjny przedstawia nadrzędne jednostki organizacyjne, którym podległe mogą być mniejsze jednostki. W ramach jednostek organizacyjnych wydzielić można poszczególne stanowiska, a im z kolei przypisać pracujące na tych stanowiskach osoby.

Przebudowanie organizacji zmierzać będzie w zmianę istniejącej w większości przypadków struktury funkcjonalnej w nową strukturę – organizację zorientowaną na procesy. Prof. Scheer w referencyjnym modelu organizacji funkcjonalnej wyróżnia następujące nadrzędne jednostki organizacyjne:

-dział sprzedaży i marketingu;
-dział rozwoju produktu;
-dział produkcji;
-dział zakupów;
-dział zarządzania zasobami ludzkimi;
-dział rozliczeń;
Natomiast w organizacji zorientowanej na procesy funkcjonować będą jednostki organizacyjne oparte o następujące procesy nadrzędne:

-procesy logistyczne;
-procesy rozwoju produktu;
-procesy informacyjne i koordynacji;

W strukturze funkcjonalnej poszczególne działy odpowiedzialne są za wszystkie produkty firmy w ramach swojego zakresu działania. Pracownik jest ściśle wyspecjalizowany w ramach swoich obowiązków. Jednak wadą tego typu organizacji jest słaba komunikacja pomiędzy poszczególnymi działami, w strukturach tych występują często odrębne dla każdego działu systemy informatyczne. Dzięki przebudowie struktury firmy na organizację zorientowaną na procesy, ułatwia się wdrożenie wspólnego, zintegrowanego sytemu informatycznego obejmującego wszystkie aspekty funkcjonowania organizacji. Udane wdrożenie takiego systemu jest podstawą dla sprawnej komunikacji pomiędzy różnymi jednostkami organizacyjnymi.

Perspektywa danych

Zadaniem perspektywy danych jest ukazanie związanych z procesem danych oraz relacji między nimi. W tym celu ARIS wykorzystuje często używany model eERM (extended Entity-Relationship Model). Model eERM jest rozwinięciem modelu ERM, wprowadzonego przez P. Chena w 1976 roku.

Model ERM wyróżnia obiekty informacyjne (entities, nazywane w terminologii informatycznej encjami), opisujące je atrybuty (attributes) oraz relacje między nimi (relationships). Encje są obiektami istniejącymi i rozróżnialnymi spośród innych obiektów. Pod pojęciem typu encji rozumiemy encje cechujące się tym samym zestawem atrybutów. Encje należące do tego samego typu różnią się między sobą wartościami tych atrybutów.

W zależności od kontekstu, w jakim występuje dany parametr, może występować on raz jako encja, a raz jako atrybut. Na przykład adres klienta może być atrybutem opisującym encję „klient”, ale może być również z drugiej strony osobną encja połączoną z encja „klient” relacją „przebywa w”.

Model eERM definiuje również określony sposób czytania diagramów, przedstawiających encje i powiązania między nimi – diagramy czytane są od lewej do prawej, z racji tego, że rodzaj relacji zwykle pozwala jedynie na interpretację zależności w jednym kierunku (na przykład związek „dostawca dostarcza część” w drugą stronę interpretowany byłby jako „część dostarcza dostawcę” – co oczywiście jest wykluczone przez jednokierunkowość czytania diagramów).

Wyróżnić możemy również typ relacji, ponieważ pomiędzy różnymi encjami występować może taki sam rodzaj relacji. Wyróżnić możemy cztery rodzaje relacji:

1:1 – relacje jeden do jednego – relacja przyporządkowuje jedynie jedną encję do innej jednej encji - na przykład „jeden schemat opisuje jedną część”
1:n – relacje jeden do wielu – relacja do jednej encji przyporządkowuje wiele innych encji – na przykład „jeden pracownik pracować może w wielu departamentach”
n:1 – relacje wiele do jednego – relacja do wielu encji przyporządkowuje jedną inną encję – na przykład „wiele zamówień obsługiwanych jest przez jednego pracownika”
n:m – relacje wiele do wielu – relacja do wielu encji przyporządkowuje wiele innych encji – na przykład „wielu pracowników pracuje w wielu projektach”
W celu zwiększenia przejrzystości modelu danych wiele encji i relacji reprezentowane mogą być przez klaster (cluster). Klastery, oprócz encji i relacji, zawierać mogą również inne klastery.

Pewną trudnością w modelowaniu danych mogą być różne interpretacje pojęć przez osoby z różnych działów firmy. Pracownik działu zakupów inaczej pojmuje termin zamówienie, niż pracownik działu produkcji. Z tego powodu w ARISie występuje symbol oznaczający termin techniczny (technical term), który pozwala przypisać używane w organizacji terminy do informacji występujących w modelu.

Oprócz modelu eERM w ARISie występuje również diagram alokacji atrybutów eERM (eERM Atribute Allocation Diagram), w którym do encji przypisuje się atrybuty, zdefiniować można również klucze podstawowe (primary keys – identyfikujące encję wśród innych encji tego samego typu) oraz klucze obce (external keys – łączą encje z innymi encjami).

Alternatywnymi formami reprezentacji danych są inne niż eERM odmiany ERM – na przykład SAP ERM lub SeDaM (Semantic Data Model). W modelach tych zrezygnowano z osobnego symbolu dla relacji, co znosi również konieczność interpretacji modelu „od lewej do prawej”.

Za pomocą modeli zbudowanych w perspektywie danych obrazuje się system informacyjny procesu, przez co wyeliminować możena zbędne z punktu widzenia procesu informacje, przeprojektować relacje pomiędzy obiektami informacyjnymi, odpowiednio zaprojektować kanały przepływu informacji w organizacji. Perspektywa ta stanowi zatem bazę dla wdrażania funkcjonujących w organizacji systemów informatycznych.

Perspektywa funkcji

Funkcja jest działaniem, wykonywanym na danym obiekcie w celu wsparcia jednego lub wielu zadań, które osiągnąć ma organizacja. Funkcje elementarne (elementary functions) to takie funkcje, które nie mogą być dalej dzielone z punktu widzenia procesu biznesowego.

W perspektywie funkcji hierarchię pomiędzy funkcjami przedstawia się za pomocą drzewa funkcji (function tree). Drzewo takie stanowi statyczne przedstawienie funkcji istniejących w organizacji. Drzewo funkcji ukazuje powiązania pomiędzy funkcjami w sposób statyczny, gdyż nie można za jego pomocą ukazać kolejności funkcji w procesie. Umożliwia to znajdujący się w perspektywie sterowania model eEPC.

W drzewie funkcji występuje jedynie symbol funkcji oraz powiązania (relacje) pomiędzy funkcjami. Funkcje w drzewie uporządkowane są w sposób ukazujący hierarchie pomiędzy poszczególnymi działaniami. Najwyższą hierarchię w drzewie maja funkcje nadrzędne w przedsiębiorstwie – na przykład gospodarka magazynowa, sprzedaż, produkcja (zazwyczaj nazwy tych funkcji mają formę rzeczownika), a w ramach tych funkcji wydzielane są funkcje podrzędne – na przykład z funkcji „produkcja” wydzielić można funkcje planowania i sterowania produkcją. Na najniższej hierarchii drzewa znajdują się funkcje elementarne. Zwykle diagram tworzy się w taki sposób, że funkcje o najwyższej hierarchii umieszczone są na górze drzewa, a elementarne – na dole.

Wyróżnić można następujące kryteria grupowania funkcji podrzędnych:

-zorientowane na obiekt (object oriented) – funkcje operują na tym samym obiekcie – na przykład z nadrzędnej funkcji obsługi zlecenia produkcji wydzielić można funkcje utworzenia zlecenia produkcji, potwierdzenia zlecenia, aktualizacji zlecenia, odwołania zlecenia, monitorowania zlecenia;
-zorientowane na zadanie (task oriented) – funkcje operują na tych samych zadaniach – na przykład z funkcji aktualizacji obiektów wyróżnić można funkcje aktualizacji zamówień, aktualizacji zleceń produkcji, aktualizacji planów produkcji, aktualizacji planów kontroli;
-zorientowane na proces (process oriented) – funkcje operują w ramach tego samego procesu – na przykład z funkcji przetwarzania zamówienia klienta wydzielić można funkcje przyjęcia zamówienia, sprawdzenia zamówienia, wprowadzenia danych klienta, sprawdzenia wypłacalności klienta, sprawdzenia dostępności produktu, potwierdzenia zamówienia;

Innym typem modelu występującego w perspektywie funkcji jest diagram Y (Y diagram). Diagram ten ukazuje powiązania pomiędzy nadrzędnymi funkcjami organizacji, a jego nazwa pochodzi od charakterystycznego kształtu diagramu w kształcie litery Y. W lewej gałęzi litery Y umieszczone są funkcje administracyjno - zarządcze (przetwarzanie zamówień, planowanie potrzeb materiałowych, kontrola), a w prawej – techniczne funkcje związane z produktem i produkcją (projektowanie produktu, planowanie pracy, sterowanie maszynami, sterowanie zapasami). Na szczycie litery Y znajdują się funkcje związane z planowaniem, na dole – funkcje związane ze sterowaniem i wykonaniem planu. Diagram ten pomóc może w porównaniu funkcji w organizacji w odniesieniu do modeli referencyjnych.

W perspektywie funkcji występuje również diagram zadań (objective diagram) - umożliwia on przedstawienie celów organizacji, ich hierarchii oraz czynników zapewniających ich osiągnięcie.

Na poziomie specyfikacji projektowej w perspektywie funkcji używany jest diagram typów aplikacji (application system type diagram), który zawiera specyfikację systemu informatycznego, a w przypadku aplikacji o modularnej strukturze - poszczególnych modułów systemu. Zawrzeć można również opisy poszczególnych ekranów aplikacji (służących do prezentacji danych oraz ich wprowadzania przez użytkowników) oraz opisy transakcji (poszczególnych operacji na danych – przykładem transakcji może być na przykład sprawdzenie stanu konta w systemie bankowym).

Zaprojektowane na poziomie definiowania wymagań funkcje są na poziomie specyfikacji projektowej podstawą do zbudowania systemu informatycznego. W tym miejscu następuje wybór rodzaju technologii informatycznej, systemu operacyjnego dla aplikacji, jak również wybór systemu bazy danych (DBMS). W oparciu o zdefiniowane wcześniej funkcję dokonuje się zaprojektowania interfejsu użytkownika na różnych obszarach działania systemu. W przypadku rozbudowanych aplikacji zaprojektować można moduły tworzące jej elastyczną, modularną strukturę.

Podstawowym symbolem używanym w diagramie typów aplikacji jest typ aplikacji (application system type). Symbol modułu (module type) przedstawia moduł, który jest komponentem aplikacji, mogącym również działać również niezależnie od innych modułów. Funkcje informatyczne (IT functions) są pojedynczymi procedurami działającymi w ramach modułów, najczęściej realizującymi poszczególne transakcje.

W diagramie typów aplikacji zobrazować można, które z modułów aplikacji odpowiedzialne są za wykonanie opisanych wcześniej w definicji wymagań określonych funkcji procesu. Dla każdej aplikacji określić można też system operacyjny, w którym ma ona działać.

W perspektywie funkcji najniższy poziom – implementacji – obrazuje diagram aplikacji (application system diagram). Aplikacją (application system) nazywa się pojedynczą kopię typu aplikacji (na przykład jedna kopia programu, identyfikowana przez numer licencji). W diagramie aplikacji ukazać można również strukturę aplikacji poprzez użycie symbolu modułu programu (program module), przedstawiającego na przykład pojedyncze pliki typu EXE lub DLL.

Dzięki perspektywie działań możliwe staje się wyodrębnienie można funkcji, które wykonywane są bez uzasadnienia wielokrotnie, a także określenie, które funkcje i czynności są zbędne dla procesu. Perspektywa ta pomóc również może w ustaleniu zakresu czynności dla pracowników zajmujących różne stanowiska w strukturze organizacyjnej firmy.

Perspektywa sterowania

Najbardziej kompleksowy obraz procesu ukazuje perspektywa sterowania (control view). W perspektywie tej zobrazować można relacje, które zachodzą pomiędzy elementami pozostałych trzech perspektyw (danych, organizacji i funkcji).

Diagram eEPC (event-driven Process Chain) umożliwia przedstawienie procesu jako łańcucha naprzemiennie następujących po sobie wydarzeń i działań. W występującym w perspektywie funkcji drzewie funkcji ukazane mogą być jedynie zależności pomiędzy poszczególnymi działaniami. Dopiero w diagramie eEPC ukazać można w chronologiczny sposób kolejność, w jakiej występują poszczególne działania w procesie.

Poprzez zdarzenie (event) rozumie się fakt, iż obiekt przyjął stan, w którym steruje lub wpływa na dalszy przebieg procesu. Zdarzenia inicjują działania, a zarazem są ich rezultatem. W odróżnieniu od działań, zdarzenia nie trwają w czasie, są powiązane tylko z jednym punktem czasu. Każdy proces zaczyna się wydarzeniem inicjującym, a kończy się wydarzeniem kończącym proces.

W niektórych przypadkach nastąpić może rozgałęzienie procesu w sytuacji, gdy rozdziela się on na czynności wykonywane równolegle, bądź wtedy, gdy występuje wiele wariantów przebiegu procesu – na przykład jedno działanie może powodować jedno lub wiele zdarzeń. Do zobrazowania tej sytuacji w ARISie służą operatory logiczne – operator XOR, operator OR oraz operator AND, które wykorzystywane są zarówno do rozdzielenia procesu, jak i do połączenia dwóch lub wielu jego gałęzi.

Umieszczenie na diagramie operatora XOR oznacza, że po zakończeniu danego działania występuje wiele wariantów dalszego przebiegu procesu, jednak w danym przebiegu nastąpić może tylko jeden wariant, ponieważ alternatywne możliwości wykluczają się wzajemnie.

Operator OR występuje w sytuacji, gdy w wyniku zakończenia działania dojść może do wykonania jednego lub kilku wariantów procesu.

Operator AND wykorzystywany jest gdy proces rozdziela się na dwa lub wiele wykonywanych równolegle podprocesów. Rozdzielenie to wystąpić może zarówno jako efekt wydarzenia, jak i działania i jest to jedyny operator, który może być umieszczony po wydarzeniu.

W programie ARIS działania przedstawione mogą być również jako osobne podprocesy poprzez opisanie ich za pomocą odrębnych diagramów typu eEPC. W ten sposób rozbija się działania o charakterze nadrzędnym na bardziej uszczegółowiony ciąg działań.

W diagramie eEPC z działaniami powiązać można również inne elementy, znane z poprzednich perspektyw – jednostki organizacyjne, stanowiska, osoby wewnętrzne i zewnętrzne, dokumenty, lokalizacje, klastery danych, typy aplikacji oraz wiele innych typów obiektów.

Ponieważ diagram eEPC umożliwia przedstawienie tak wielu występujących w ARISie obiektów i występujących powiązań między nimi, w przypadku mniej złożonych modeli może być jedynym typem modelu opisującym proces. Ukazać można na nim bowiem proces z punktu widzenia wszystkich występujących w ARISie perspektyw. Podobny do diagramu eEPC jest diagram PCD (process chain diagram), w którym poszczególne typy obiektów umieszczane są w uporządkowany sposób w odpowiednich kolumnach.

Inny występujący w perspektywie sterowania typ diagramu - diagram alokacji funkcji wejścia/wyjścia (function allocation diagram (I/O)) – umożliwia przypisanie działaniom odpowiednich danych wejściowych i wyjściowych. Diagram ten wiąże zatem elementy perspektywy funkcji z elementami perspektywy danych. Dane najczęściej reprezentowane są za pomocą klasterów, w charakterze tym występować mogą również (na wyższym poziomie uszczegółowienia) encje czy typy relacji. Powiązania tego typu przedstawić można również w diagramie eEPC, jednak często wiązać się to może z mniejszą czytelnością modelu.

W obrazowy sposób tworzenie wartości w organizacji przedstawić może diagram łańcucha wartości dodanej (value-added chain diagram). W diagramie tym umieszczone powinny być działania, które wnoszą dodatkową wartość do przedsiębiorstwa. Działania przedstawione są za pomocą symboli strzałek, a sposób ich połączenia obrazuje kierunek powstawania wartości dodanej w organizacji. Na wzór drzewa funkcji z działań nadrzędnych wydzielić można działania podrzędne i również wśród tychże działań podrzędnych ukazać kierunki tworzenia wartości dodanej.

W diagramach eEPC i PCD użyć można również symbolu ogólnego operatora logicznego (general rule operator), któremu następnie przyporządkowuje się diagram operatorów (rule diagram), który obrazuje operator ogólny za pomocą podstawowych operatorów OR, XOR i AND.

Obiektom występującym w modelach przypisany jest odpowiedni dla nich zestaw atrybutów. I tak wydarzeniom przypisać możemy częstotliwość, z jaką występują (frequency), szczególnie ważna dla zdarzenia inicjującego proces w diagramie eEPC. Działaniom natomiast przypisać możemy czas, który pochłania ich wykonywanie (processing time), czas oczekiwania na wykonanie działania (static wait time), jak również koszty działania – materiałowe (material costs), personalne (personnel costs), energii (energy costs), jak również inne rodzaje kosztów. Użyć można też łączącego wszystkie koszty cząstkowe kosztu całkowitego (total costs). Dla kosztów i czasów określić można zarówno ich minimalne i maksymalne, jak i średnie wartości. Dla jednostek organizacyjnych określona może być ilość pracowników, którzy pracują w danej jednostce. Podane powyżej atrybuty ważne są szczególnie wtedy, gdy przeprowadzona ma zostać symulacja modelu bądź analiza kosztów metodą ABC.