Faza III: Budowa strategii i planu operacyjnego (obszar właściwego wspomagania decyzji) Prawidłowo zakończona faza budowy modelu (dyskutowana i zatwierdzona jakościowo)
6.4.2 Rozwiązanie problemu decyzyjnego z wykorzystaniem zaprojektowanej architektury systemu informatycznego
W Rozdziale czwartym zaproponowano koncepcje dostarczenia decydentowi uniwersalnej architektury SWD, który można wdrożyć dla problemów wspomagania decyzji w transferze technologii. Celem właściwej weryfikacji zdefiniowanej koncepcji dokonano jego implementacji zgodnie z określoną uprzednio specyfikacją systemu informatycznego (wariant W1). Architektura systemu informatycznego przewiduje podział na funkcjonalne moduły tworzące, tzw. model warstwowy SWD (rozdział czwarty). Interakcje poszczególnych elementów zobrazowano na Rys. 4.1 i Rys. 4.2. Można nadmienić, że podmioty implementujące wskazane środowisko SWD mogą dokonać indywidualnego doboru modułów aplikacji, jakie chcą wykorzystać do rozwiązania własnego problemu decyzyjnego. Pewne elementy proponowanej architektury są bezwzględnie wymagane do prawidłowego funkcjonowania oprogramowania. Należą do nich: warstwa analityczna równorzędnie z warstwą modelowania. Pozostałe, wyszczególnione na diagramie warstwy, mają charakter opcjonalny i realizują wsparcie procesu budowy modelu oraz procesu analitycznego, na podstawie zgromadzonej uprzednio informacji oraz wiedzy.
Elastyczność proponowanej architektury pozwala na możliwość rekonfiguracji systemu zależnie od aktualnego zapotrzebowania decyzyjnego. Wybrane warstwy w modelu warstwowym systemu mogą mieć implementowane w czasie dodatkowe metody przetwarzania informacyjnego. Te nowe metody realizują wzrost zapotrzebowania informacyjnego całego systemu. Możliwość dowolnego doboru metod i ich priorytetyzowania stanowi wyznacznik hybrydowej architektury systemu (zgodnie z modelem systemu, Rozdział czwarty). Przykład użytkowania różnych wzorców SWD w całym cyklu przeprowadzenia testu przestawiono w Tab. 6.8. Dodatkowo przyjęte podejście pozwala na realizację procesu wspomagania decyzji zgodnie z opracowanymi procedurami oraz innymi wewnętrznymi wytycznymi (np. normy ISO czy ITIL; w Rozdziale trzecim i w Rozdziale
czwartym rozszerzono tę kwestię). Wraz z aplikacją dostarczono dodatkowe mechanizmy
pozwalające na edycję istniejących procedur oraz norm, a także na tworzenie nowych schematów zarządzania procesem (tzw. Workflow). Dodatkowo najbardziej efektywnym rozwiązaniem implementacji decyzyjnych jest skorzystanie z koncepcji występujących w systemach typu MIDS oraz EIS, tj. budowa zintegrowanego portalu zarządzania procesem decyzyjnym dostosowanego do umiejscowienia danego aktora w procesie informacyjnym. Budowa portalu korporacyjnego zaimplementowanego w technologii Microsoft Sharepoint, pozwala na realizację wszystkich założeń użytkowych oraz konstrukcyjnych. Zasadą nadrzędną wykorzystaną podczas implementacji stało się dostarczenie wymaganych treści bezpośrednio użytkownikowi, tworząc tzw. indywidualne widoki procesowe (ang. individual process view, skrót IPV). Proces jest realizowany w systemie zgodnie z kolejnością faz RM przedstawioną w poprzednim punkcie.
Tab. 6.8 Użytkowane wzorce SWD dla różnych metod scenariusza testowego PP_II.
Zadanie Nazwa Grupy Zakres operacyjny Wzorzec SWD
Scenariusz Metoda Specyfikacja
1. Gr_1_x Zarządzanie nadzór procesem Wariant 1
communication-based metody ułatwiających komunikacje oparte o Sharepoint, poczta e-mail, zarządzanie procesem (workflow) Wariant 2
communication-based
klasyczne techniki komunikacji elektronicznej Wariant 3
communication-based klasyczne techniki komunikacji elektronicznej 2. Gr_2_x Panel: Warstwa Badania Wariant 1 communication-based, model-based, data-based, knowledge-based
metody ułatwiających komunikacje oparte o Sharepoint, zarządzanie procesem
(workflow), poczta e-mail, forum tematyczne, Skype, rekomendery modelu,
wizualne modelowanie, przetwarzanie danych celem ekstrakcji trendów
Wariant 2
communication-based klasyczne techniki komunikacji elektronicznej Wariant 3
communication-based
klasyczne techniki komunikacji elektronicznej 3. Gr_3_x Panel: Warstwa Technologie Wariant 1 communication-based, model-based, data-based, knowledge-based
metody ułatwiających komunikacje oparte o Sharepoint, zarządzanie procesem
(workflow), poczta e-mail, forum tematyczne, Skype, rekomendery modelu,
wizualne modelowanie, przetwarzanie danych celem ekstrakcji trendów
i scenariuszy cząstkowych Wariant 2
communication-based klasyczne techniki komunikacji elektronicznej Wariant 3
communication-based
klasyczne techniki komunikacji elektronicznej 4. Gr_4_x Panel: Warstwa Produkty Wariant 1 communication-based, model-based, data-based, knowledge-based
metody ułatwiających komunikacje oparte o Sharepoint, zarządzanie procesem
(workflow), poczta e-mail, forum tematyczne, Skype, rekomendery modelu,
wizualne modelowanie, przetwarzanie danych celem ekstrakcji trendów
i scenariuszy cząstkowych Wariant 2
communication-based klasyczne techniki komunikacji elektronicznej Wariant 3
communication-based klasyczne techniki komunikacji elektronicznej 5. Gr_5_x Panel: Warstwa Rynki Wariant 1 communication-based, model-based, data-based, knowledge-based
metody ułatwiających komunikacje oparte o Sharepoint, zarządzanie procesem
(workflow), poczta e-mail, forum tematyczne, Skype, rekomendery modelu,
wizualne modelowanie, przetwarzanie danych celem ekstrakcji trendów
i scenariuszy cząstkowych Wariant 2
communication-based
klasyczne techniki komunikacji elektronicznej Wariant 3
communication-based klasyczne techniki komunikacji elektronicznej 6. Gr_1-5_x Panel: Integracja wiedzy oraz modelowanie I Wariant 1 communication-based, model-based, knowledge-based
metody ułatwiających komunikacje oparte o Sharepoint, zarządzanie procesem
(workflow), poczta e-mail, forum tematyczne, Skype, rekomendery modelu,
wizualne modelowanie, przetwarzanie danych celem ekstrakcji trendów
i scenariuszy cząstkowych Wariant 2
communication-based klasyczne techniki komunikacji elektronicznej Wariant 3
communication-based klasyczne techniki komunikacji elektronicznej 7. Gr_1-5_x Panel: Integracja wiedzy oraz modelowanie II Wariant 1 communication-based, model-based, knowledge-based
metody ułatwiających komunikacje oparte o Sharepoint, zarządzanie procesem
(workflow), poczta e-mail, forum tematyczne, Skype, rekomendery modelu,
wizualne modelowanie, algorytm analityczny
Wariant 2 communication-based
klasyczne techniki komunikacji elektronicznej Wariant 3
communication-based
klasyczne techniki komunikacji elektronicznej 8. Gr_1-5_x Panel: Podejmowanie decyzji Wariant 1 communication-based, model-based, knowledge-based
metody ułatwiających komunikacje oparte o Sharepoint, zarządzanie procesem
(workflow), poczta e-mail, forum tematyczne, Skype, rekomendery modelu,
wizualne modelowanie, algorytm analityczny
Wariant 2 communication-based
klasyczne techniki komunikacji elektronicznej
Wariant 3 communication-based,
model-based
klasyczne techniki komunikacji elektronicznej, algorytm analityczny
9. Gr_1-5_x Wdrożenie procesu Wariant 1
communication-based, model-based,
knowledge-based
metody ułatwiających komunikacje oparte o Sharepoint, zarządzanie procesem
(workflow), poczta e-mail, forum tematyczne, Skype, rekomendery modelu,
wizualne modelowanie Wariant 2
communication-based
klasyczne techniki komunikacji elektronicznej Wariant 3
communication-based, model-based
klasyczne techniki komunikacji elektronicznej, algorytm analityczny
Źródło: Opracowanie własne.
Rys. 6.13 Ekran Powitalny. Źródło: Opracowanie własne.
Ekran główny systemu stanowi zintegrowany pulpit zarządzania procesem decyzyjnym, który może być indywidualizowany dla każdej grupy użytkowników, w zgodzie z przydzielonymi mu uprawnieniami lub funkcjami w systemie informacyjnym. Przykład ekranu powitalnego został przedstawiony na Rys. 6.13. Strona ta integruje w jednym miejscu odpowiednie odnośniki umożliwiające dostęp do innych zasobów.
Zakres treści na stronie jest definiowany zgodnie ze schematem narzuconym przez administratora, który może być dobierany indywidualnie zgodnie z zadaniami oraz jego rolą w procesie podejmowania decyzji (Faza I-IV np. ekspert, decydent, gość, itp.). Celem realizacji wskazanej funkcji zaimplementowano bogaty aparat przyznawania uprawnień na portalu SWD. Przykładowo na rysunku Rys. 6.14 przedstawiono wielopoziomowy aparat przyznawania uprawnień do procesów w systemie decyzyjnym.
Rys. 6.14 Definicja wielopoziomowych uprawnień użytkowników i grup. Źródło: Opracowanie własne.
Dostęp do zasobów jest autoryzowany na poziomie usług katalogowych (Active Directory, skrót
AD) przez potwierdzenie uprawnień za pomocą logowania na konto użytkownika lub na poziomie
certyfikatów SSL połączonych z kontem. Ponadto administratorom dostarczono szereg narzędzi pozwalających użytkownikom oraz ich grupom na dowolne kształtowanie polityk dostępu do zasobów. Proces decyzyjny wymusza konieczność swobodnego kształtowania uprawnień do zasobów, metod i procesów stosownie do modelu decyzyjnego w danej organizacji. Przykładowe formatki pozwalające na generowanie uprawnień do zasobów przedstawiono na Rys. 6.14 oraz Rys. 6.15.
Realizacja fazy II i III w systemie informatycznym wymaga zaangażowania szeregu metod specyficznych dla różnej klasy SWD (HS_IV). Dobór udostępnionych i użytkowanych metod zależy od zapotrzebowania konsumenta (zespołów zadaniowych) na dostęp do konkretnych zasobów informacyjnych. Oznacza to możliwość dynamicznej rekonfiguracji architektury systemu o dodatkowe lub uruchomienie zaimplementowanych już metod. Opierając sposób funkcjonowania systemu o przedstawiony profil działania otrzymuje się tzw. hybrydowy SWD (HS_IV). Podstawowe klasy metod udostępnionych w systemie informatycznym należą do kategorii: model-driven (metoda zdefiniowana w Rozdziale piątym), knowledge-based (Rozdział czwarty, Rozdział piąty), data-driven (metody akwizycji informacji, Rozdział czwarty), communication-based (Rozdział czwarty). Element kooperacji w metodach roadmappingu inicjujących wiele procesów stanowią wzorce systemów communication-based s bazujące na rozwiązaniach Web 2.0.
Rys. 6.15 Zarządzanie użytkownikami i grupami wraz z przydziałem uprawnień. Źródło: Opracowanie własne.
Rys. 6.16 Planowanie i nadzorowanie procesu RM z poziomu użytkownika. Źródło: Opracowanie własne.
Ten wzorzec bazuje głównie na elementach pracy grupowej, np. informator and announcement
point (skrót, IAP), różnego typu forum wymiany informacji (z reguły skupione na pewnym temacie),
kalendarz z terminami użytkownika (Rys. 6.16), listy dedykowane publikacji zasobów (Rys. 6.17), dynamiczne strony zadaniowe dedykowane współpracy zespołów na potrzeby decyzyjne (Rys. 6.18). Implementacja dedykowanych tzw. Workspace pozwala na tworzenie obszarów fokusowych na wybranym temacie analitycznym. W tym przypadku określonym procesom modelowania struktury warstw identyfikowanych na MD, Faza II. Podobna architektura zadań jest użytkowana w Fazie III (HS_IV) do analizy wspartej procesem wspomagania decyzji (HS_V).
Rys. 6.17 Jedna z dedykowanych list współdzieleniu wiedzy (analiza bibliometryczna). Źródło: Opracowanie własne.
Udostępniono wachlarz dodatkowych narzędzi wspomagających aspekt pracy grupowej, np. harmonogramowanie i planowanie procesu (Rys. 6.16), który pozwala na bezpośrednie zarządzanie aktywnością użytkownika oraz innych osób w zespole. Proces roadmappingowy jest nadzorowany procesowo podobnie, jak się to ma w przypadku zarządzania projektem. Struktura ekranu powitalnego, zaraz po zalogowaniu, wyświetla zadania przydzielone danemu użytkownikowi w ramach aktywności zespołu bądź indywidualnie. Stworzony w ten sposób mechanizm pracy usprawnia proces decyzyjny, pozwalając na bezpośredni nadzór nad każdym elementem procesu zgodnie z opracowanymi procedurami.
Rys. 6.18 Workspace Warstwa Badania- integracja działań grup zadaniowych skupiona wokół jednego zakresu roboczego.
Źródło: Opracowanie własne.
Realizacja zadań procesu wspomagania decyzji jest zgodna z diagramem zawartym na Rys. 4.7-Rys. 4.11, wymaga użytkowania hybrydowego SWD (HS_IV). Potencjalnemu użytkownikowi udostępniono narzędzia pracy na trzech zasadniczych płaszczyznach: pracy grupowej (workspace), warstwy procesowej (workflow) oraz warstwy modelowania (interaktywna budowa diagramów RM, opis parametrów, definicja kryteriów, itd.). Model communication-based musi być
wsparty przez algorytm wspomagania decyzji oparty na metodach optymalnego sterowania. Zgodnie ze schematem podejmowania decyzji zdefiniowanym w Rozdziale czwartym (por. Rys. 4.6), proces podzielono na kilka części funkcjonalnych (zgodnie z Dodatku 0.2): zadania przygotowawcze (1), modelowanie zagadnienia problemowego (2), analiza oraz przygotowanie rekomendacji dla decydentów (3), planowanie wdrożenia oraz działań uzupełniających (4). Aplikacja wspiera każdy z powyżej wymienionych aspektów procesowych dostarczając odpowiednich metod logistycznych do ich obsługi wraz z możliwością elastycznego dostosowania komponentów systemu do wdrożenia w każdym podmiocie implementującym SWD w TT w przyszłości.
Rys. 6.19 Proces specyfikacji potencjalnych obszarów i celów analizy. Źródło: Opracowanie własne.
Rys. 6.20 Proces specyfikacji potencjalnych źródeł informacji (identyfikacja). Źródło: Opracowanie własne.
Aspekt procesowy (1) został zrealizowany z wykorzystaniem, tzw. przestrzeni współpracy (workspace) widocznych na Rys. 6.18, gdzie możliwe jest zdefiniowanie obszaru interakcji zespołu (w tym przypadku nadzorującego proces decyzyjny). Workspace, w tym przypadku, umożliwia zdefiniowanie podstawowych celów danej czynności procesowej, budowę odpowiednich repozytoriów dokumentów i wiedzy oraz pozwala na jasną definicję decyzji, tj. zaplanowanie procesu decyzyjnego, oddelegowanie zadań oraz uprawnień. Aspekt procesowy (2) modelowanie zagadnienia
problemowego w aplikacji podzielono na dwie zasadnicze fazy: zdefiniowanie /wstępna specyfikacja problemu (2-I) oraz właściwe modelowanie zagadnienia problemowego zgodnie z przygotowaną w uprzednim kroku specyfikacją (2-II). Obydwa zadania opierają się na użytkowaniu metod nadzoru procesu zgodnych z opracowanymi procedurami, tzw. przepływ pracy. Bezpośrednio one implementują zadania zgodne z metodą roadmappingu technologicznego (Rozdział 2-4, Dodatku 0.2 ). Każdy z workflow zapewnia również realizacje zadań synchronizacji działań i wspomaga proces komunikacji pomiędzy użytkownikami za pomocą poczty email, przydziału i kontroli wykonywania szczegółowych zadań (przekazywanie/ informowanie o stanie zadań), itd.
W przypadku zadania specyfikacji (2-I), na wstępie zostają sprecyzowane takie elementy, jak: x obszary oraz cele modelowania – określenie głównych celów, potrzeb oraz wymagań
docelowych (zdefiniowanie kompetencji procesu),
x dane – zdefiniowanie potencjalnych źródeł danych, informacji oraz wiedzy (ocena i hierarchizacja źródeł),
x problemy – dekompozycja problemu głównego na problemy elementarne, wraz z określeniem sposobu ich rozwiązania (budowa struktury oraz jej dekompozycja).
Przykładowe formatki realizujące funkcje procesowe dekompozycji zagadnienia problemowego w transferze technologii przedstawiono odpowiednio na Rys. 6.20-Rys. 6.25.
Rys. 6.21 Proces specyfikacji potencjalnych problemów związanych z tematem analizy (jeśli jest zatwierdzony, wówczas podlega ocenie).
Źródło: Opracowanie własne.
Powyższe pierwotne zadania problemowe na kolejnym etapie workflow są dekomponowane lub agregowane w funkcjonalne zadania elementarne. Proces ten został przedstawiony na Rys. 6.21.
Zadania elementarne przechodzą następnie przez proces weryfikacji i odpowiednie zespoły zadaniowe, co zostało zobrazowane na Rys. 6.22. W przypadku, gdy powstają pewne niejasności odnośnie zadania (np. brak spójności), zostaje ono ponownie skierowanie do prac merytorycznych lub odrzucone.
Zadania, które przejdą poprawną weryfikację tworzą, tzw. sztywną specyfikację procesu AATDP, co zostało przedstawione na Rys. 6.23. Specyfikacja staje się podstawą roboczą na etapie właściwego modelowania zagadnienia problemowego, co zostaje przekazane do fazy implementacji (2-II). Na tym etapie możliwe jest właściwe rozdzielenie zadań w grupach zadaniowych oraz wyłonienie liderów zadań, z reguły dla zbioru zadań (np. modelowanie warstw, itd.).
Rys. 6.22 Definicja zadań jednostkowych na etapie specyfikacji (ilustracja wykres Gantta). Źródło: Opracowanie własne.
Rys. 6.23 Ewaluacja zadań specyfikacji. Źródło: Opracowanie własne.
Rys. 6.24 Utworzenie specyfikacji RM. Źródło: Opracowanie własne.
Rys. 6.25 Definicja zadań elementarnych dla procesów implementacji.
Źródło: Opracowanie własne.
Drugi etap modelowania (2-II) zakłada przeprowadzenie właściwej fuzji wiedzy bazując na różnych źródłach danych, informacji i wiedzy. Powyższe elementy determinowane przez model warstwowy są pozyskiwane na poziomie warstwy zarządzania oraz akwizycji wiedzą (HS_II-HS_III). Proces zarządzania wiedzą na potrzeby systemu decyzyjnego jest zgodny z podstawą zapisu modeli SZD i teorią hiperautomatów zawartą w Rozdziale piątym. Proces akwizycji wiedzy od strony technicznej został omówiony w rozdziale czwartym. Działanie algorytmu RM
opracowanego w rozprawie na tym etapie rozpoczyna się od przydzielenia grupom roboczym zadań zgodnych z wypracowaną specyfikacją zagadnienia problemowego (Rys. 6.24). Przykładowy zrzut ekranowy formatki zarządzania wstępnego procesu modelowania zawarto na Rys. 6.25. Właściwy proces modelowania zawsze jest przeprowadzony zgodnie z otrzymaną główną specyfikacją procesu AADTP. Następnie każde zdanie jednostkowe budowy wizji pewnego fragmentu problemu jest modelowane w określonym uprzednio zakresie (interakcyjna konstrukcja diagramu RM modelującego badane zjawisko). Na tym etapie, praca rozpoczyna się od zdefiniowania szczegółowych zadań elementarnych modelowania, z wyszczególnieniem ich zakresu (Rys. 6.25). Użytkownicy wykorzystują mechanizm aplikacji typu workflow pozwalający na zarządzanie nad zadaniami zgodnie z opracowanymi procedurami (od części modelowania przez weryfikacje oraz zatwierdzenie poszczególnych części składowych modelu).
Rys. 6.26 Przykładowa edycja obiektów identyfikowanych w modelu. Źródło: Opracowanie własne.
Każde zadanie elementarne modelowania jest wersjonowane, a finalnie przechodzi proces weryfikacji przez zespoły. Ze względu na złożoność diagramu, bloki funkcjonalne modelu są tworzone niezależnie, zgodnie przesłankami zawartymi w Dodatku 0.2, zadania 2 oraz 4. Model warstwowy interakcji obiektów budowany jest głównie w oparciu o mechanizmy wizualizacji trendów i scenariuszy obiektów (często wraz z mechanizmami foresight). Następnie elementy te są w procesie fuzji wiedzy z różnych źródeł scalane przez zespoły zadaniowe ekspertów i odpowiednio opisywane, np. przez dodanie opisu prekryteriów oraz kryteriów. Celem podniesienia efektywności modelowania obiektów i relacji przez ekspertów, sugeruje się delegowanie zespołom zadaniowym dedykowanych stron roboczych, tzw. Workspace (przykład Rys. 6.18). Przykładowe elementy procesu wizualizacji modelu w kontekście identyfikacji obiektów oraz relacji przedstawiono na Rys. 6.27-Rys. 6.29. Użytkownik posiada dostęp do narzędzi, które pozwalają mu na generowanie kolejnych abstrakcji pojęć przy zastosowaniu narzędzi budowy dedykowanych widoków analitycznych (ang. focused problem view, skrót FPV). W tym miejscu następuje użytkowanie metod hybrydowych realizujących HS_IV.
Rys. 6.27 Edytor relacji kauzalnych pomiędzy obiektami.
Źródło: Opracowanie własne.
Rys. 6.28 Edytor dynamiki obiektów. Źródło: Opracowanie własne.
Zespoły decyzyjne ze strony zadania eksperckiego typu workspace posiadają wgląd w aktualny ogólny model problemu planowania w transferze technologii. Przykładową formatkę zaprezentowano na Rys. 6.30.
Na etapie modelowania użytkownik otrzymuje dostęp do narzędzi zarządzania wiedzą, które pozwalają mu na budowę efektywnych struktur wiedzy dla modelowanego zagadnienia decyzyjnego (zgodne z SZD). Struktura wiedzy powstała na potrzeby systemu wspomagania decyzji, zawsze stanowi bazę hierarchiczną tworzoną zgodnie z Rys. 4.25. Przykładowo, na Rys. 4.31 przedstawiono sposób dostępu użytkownika do narzędzi rozszerzenia wiedzy (ang. merge knowledge) zgodnie z uprawnieniami. Przedstawiony sposób umożliwia konstrukcje hierarchicznych baz wiedzy przez import istniejących elementów ze współdzielonych źródeł. Działanie to pozwala na integrację bazy ontologicznej z nowymi elementami istniejącymi w repozytoriach (warstwa zarządzania wiedzą).
System ewentualnie na podstawie zaimplementowanych mechanizmów wnioskowania może rekomendować użytkownikowi pewne elementy wiedzy wymagane w procesie decyzyjnym. Jednym z elementów zarządzania wiedzą stanowi mechanizm uzupełniania wiedzy na potrzeby danego procesu decyzyjnego. Proces ten odbywa się zgodnie z Rys. 4.26 -Rys. 4.33 (HS_II). Wynikowy model realizacji tej funkcji przedstawiono na Rys. 6.32.
Rys. 6.29 Katalog zdarzeń. Źródło: Opracowanie własne.
Rys. 6.30 Workspace Rezultaty- integracja działań grup zdaniowych skupiona wokół jednego zakresu roboczego. Źródło: Opracowanie własne.
Rys. 6.31 Edytor rozszerzenia wiedzy obiektu oraz relacji. Źródło: Opracowanie własne.
Wiedza na potrzeby procesów modelowania oraz analitycznego (warstwa modelowania i analizy) może być uzupełniona za pomocą metod półautomatycznej lub automatycznej akwizycji wiedzy z innych źródeł (HS_III). W podstawowym scenariuszu użytkuje się dedykowane zlecenia systemowe, które odwołując się do odpowiednich metod wstępnego przetwarzania w formie usług. Istnieje również możliwość opracowania kolejnych metod w wersji multiplatformowej (zależnie od środowiska). Przykład funkcjonowania wskazanych botów zaprezentowano na Rys. 6.33.
Rys. 6.32 Przykładowe elementy bazy wiedzy. Źródło: Opracowanie własne.