• Nie Znaleziono Wyników

M. Mazur jako jeden z pierwszych w Polsce podjął się próby sformułowania od- od-powiedzi na pytanie czym właściwie jest informacja, jakie są jej rodzaje i czym jest sam

2. w ujęciu rzeczowym (odniesienie do rzeczy a nie procesów) (Zieleniewski, 1975, str

2.3. Teoretyczne podstawy projektowania systemów wspomagania decy- decy-zji

2.3.1. Modelowanie systemów informacyjnych

Z literatury przedmiotu znanych jest wiele sposobów projektowania systemów.

W szczególności odnoszą się one do dwóch obszarów: projektowania procesów w rach organizacyjnych (systemów informacyjnych) oraz projektowania procesów w obsza-rach informatycznych85.

Projektowanie systemów informacyjnych (obszar organizacyjny) najczęściej opi-sywany jest w literaturze poprzez standardy (notacje) modelowania procesów. By wyja-śnić sposób modelowania procesów objawyja-śnić należy kilka podstawowych pojęć związa-nych z tym zagadnieniem.

Model jest pojęciem niejednoznacznym, jednak najczęściej pod tym pojęciem rozu-mie się pewne odwzorowanie lub pewien wzorzec. Model systemu86 jest z reguły uproszczeniem rzeczywistości. Zewnętrznie taki model powinien zachowywać się po-dobnie jak system, może jednak mieć inną strukturę wewnętrzną (Findeisen, 1985, str.

339).

85 Projektowanie w obszarze systemów informatycznych zaprezentowano w kolejnym rozdziale.

86 Modele mogą być: koncepcyjne lub jakościowe, fizyczne, komputerowe lub matematyczne (Findeisen, 1985, str. 339).

73

W praktyce organizatorskiej model procesu utożsamiany jest najczęściej z powiąza-niami między poszczególnymi zdarzepowiąza-niami i działapowiąza-niami (etapami). Aby modele proce-sów były użyteczne, powinny zawierać następujące informacje (Adamczyk, 2010, str.

95):

 określenie funkcji organizacyjnych składających się na proces informacyjno-decyzyjny,

 identyfikację wykonawców kolejnych funkcji organizacyjnych,

 opis wejść i wyjść danej funkcji wchodzącej w skład procesu,

 charakterystykę powiązań między funkcjami organizacji,

 określenie powiązań z innymi procesami organizacji.

W przypadku modelowania procesów przed wdrożeniem koncepcji modelu prowa-dzone są analizy w oparciu o współczesne koncepcje zarządzania np. TQM, ABC, BSC.

Analizy prowadzone są także przed wdrożeniem systemu informatycznego. W tym celu wykorzystuje się m.in. klasy Workflow, BPM, ERP, DMS i innych (Adamczyk, 2010, str. 95-96).

Brakuje jednego wzorcowego modelu i standardu modelowania procesów, jednak w praktyce organizacyjnej i w literaturze przedmiotu znaleźć można wiele ich przykła-dów. Zazwyczaj standardy te są opracowane przez przedsiębiorstwa samodzielnie, w ramach koalicji firm lub we współpracy z ośrodkami akademickimi. Najczęściej mo-delowanie poprzedzane jest identyfikacją procesów w organizacji, a następnie mode-lowaniem właściwym złożonym z kolejnych etapów (Adamczyk, 2010, str. 97):

 analiza bieżącego stanu organizacji;

 identyfikacja procesów organizacji (opis na dużym stopniu ogólności);

 wybór procesu będącego przedmiotem identyfikacji i modelowania;

 identyfikacja głównych funkcji (najważniejszych etapów) procesu;

 identyfikacja i budowa modelu procesu w perspektywie:

a. poszczególnych funkcji organizacyjnych (cząstkowych i całościowych) składają-cych się na proces,

b. jednostek organizacyjnych wykonujących poszczególne funkcje, c. danych przetwarzanych w procesie;

d. technologii informatycznych wykorzystywanych w procesie;

e. wejść i wyjść z procesu.

 opracowanie propozycji usprawnień procesu oraz ustalenie atrybutów (np. danych wykorzystywanych przez systemy informatyczne);

74

 sporządzenie modelu procesu (najlepiej w formie mapy procesu);

 symulacja i weryfikacja poprawności modelu.

Modelowanie odnosi się do całego procesu z wyszczególnieniem każdej funkcji orga-nizacyjnej (analiza i modelowanie) składającej się na ten proces od wejścia do wyjścia z procesu i nie może odbyć się bez narzędzi, które podzielić można na (Bitkowska, 2009, str. 109):

 programy do tworzenia diagramów - przeznaczone przede wszystkim do wizualizacji i mapowania procesów np. MS Office Visio, Flowcharter (Micrografx),

narzędzia CASE (ang. Computer Aided System Engineering) - do modelowania proce-sów, wykorzystywane przede wszystkim, gdy mają być integrowane ze środowiskiem informatycznym np.: Designer/2000 (Oracle), Select Enterprise (Select Software),

 zaawansowane narzędzia projektowania i doskonalenia procesów - pozwalające na zaawansowane analizy i symulacje, np.: ARIS Toolset, Workflow Analyzer (Meta So-ftwar), Business Process Modeler Igrafx, czy narzędzia modelowania procesów w ra-mach systemów ERP (wbudowane w te systemy), np. IFS Business Modeler.

Jedną z bardziej popularnych metodyk modelowania procesów jest architektura zin-tegrowanych systemów informacyjnych ARIS (ang. Architecture of Integrated Infor-mation Systems) stworzona przez prof. Augusta Wilhelma Scheera z Uniwersytetu Saar-brucken. Modele budowane za pomocą referencyjnych metod ARIS umożliwiają (Gabryelczyk, 2006):

 dokumentację przebiegu procesów oraz wykorzystywanie modeli w procesie do ich ciągłego usprawnienia lub w ramach innych projektów,

 analizy, symulację i sprawną aktualizację modeli i procesów, a przez to szybszą reak-cję w turbulentnym środowisku,

 realizację szkoleń dla pracowników, którzy powinni zapoznać się ze zmianami wpro-wadzonymi do organizacji, by zrozumieć wykonywane przez nich funkcje w kontek-ście całego procesu tworzącego wartość.

Stworzona przez prof. Scheera koncepcja ARIS zakłada, że model procesów może być przedstawiony w czterech perspektywach (Bitkowska, 2009, str. 110):

 organizacji (ang. organization view) - w której ukazane są elementy struktury organi-zacyjnej organizacji,

 danych (ang. data view) - przedstawiającej system informacyjny organizacji,

 funkcji (ang. function view) - ukazującej występujące w procesie funkcje i powiązania pomiędzy nimi,

75

 sterowania (ang. control view) - łączącej wydarzenia, funkcje i pozostałe elementy trzech wyżej wymienionych perspektyw oraz powiązań pomiędzy nimi.

R. Gabryelczyk (Gabryelczyk, 2006) proponuje w każdej z tych sfer przeprowadzić rzetelny wywiad z wykonawcami wyżej wymienionych procesów. Każdą z wyżej wy-mienionych perspektyw zamodelowaną od problemu biznesowego do technologii infor-macyjnej opisać można trzema poziomami (Bitkowska, 2009, str. 110):

zdefiniowanie wymagań (ang. requirements definitions) – określenie wymagań dla technologii informacyjnych,

 specyfika projektowa (ang. desing specification) – sporządzenie specyfikacji systemu informacyjnego spełniającego określone wcześniej wymagania,

 opis implementacji (ang. implementation description) – przekształcenie specyfikacji we wdrożenie sprzętu komputerowego i oprogramowania jednostek organizacyjnych.

W przypadku modelowania procesów najczęściej wykorzystuje się notacje:

 EPC (ang. Event Driven Process Chain) tj. sterowany zdarzeniami łańcuch procesów –notacja zaprojektowana w latach dziewięćdziesiątych XX wieku i rozszerzona do obecnej wersji – eEPC (ang. extended Event Driven Process Chain). Notacja eEPC pozwala uwzględnić (Gabryelczyk, 2006, str. 93-98): funkcje organizacyjne, zdarzenia (wywołujące wykonanie funkcji organizacyjnych), połączenia (relacje między funk-cjami i zdarzeniami), operatory logiczne (umożliwiające prowadzenie równoległych lub alternatywnych przebiegów), jednostki organizacyjne, obiekty informacyjne, typy aplikacji komputerowych, łączniki procesu.

 BPMN (ang. Business Process Modeling Notation) – modelowanie za pomocą notacji BPMN pozwala jednoznacznie i precyzyjnie opisywać procesy biznesowe. Wszystkie procesy opisane notacją EPC można opisać także notacją BPMN. To co odróżnia BPMN od EPC to zdefiniowany formalnie metamodel, pozwalający na transformację modeli BPMN na inne modele np. gotowe fragmenty oprogramowania (Drejewicz, 2012, str. 10).

 UML (ang. Unified Modeling Language) tj. ujednolicony język modelowania obiek-towego przeznaczony do specyfikacji, konstruowania, wizualizacji i dokumentowania wytworów związanych z systemami wykorzystującymi oprogramowanie. Często UML wykorzystywany jest z BPMN w przypadku specyfikowania systemów informatycz-nych i procesów biznesowych (Drejewicz, 2012, str. 11; Bitkowska, 2009, str. 111).

Charakterystyka modelowania procesów odnosi się przede wszystkim do zdiagnozo-wania procesów i ich etapów celem wyszukania i sklasyfikozdiagnozo-wania najważniejszych

76

funkcji, które powinny być zaprojektowane w PWD. Cel projektowania PWD w SI aglomeracji jest inny - to m.in. upowszechnienie i swobodny dostęp do danych publicz-nych, celem ich wykorzystania przez pośredników danych do projektowania SI minimali-zujących lukę informacyjną uczestników aglomeracji. Sposoby modelowania SI nie w pełni odpowiadają wymaganiom stawianym przed projektowaniem PWD w SI aglome-racji. Dlatego w oparciu o badania literaturowe oraz badania własne zaprezentowano au-torską metodykę procesu projektowania PWD w SI aglomeracji.