PManager.pl

"Przekazując wiedzę o metodycznym zarządzaniu projektami chcemy sprawić,
aby realizowane przedsięwzięcia przebiegały w sposób kontrolowany i bezpieczny,
z poszanowaniem takich wartości jak: uczciwość, szacunek, odpowiedzialność,
profesjonalizm, partnerstwo i zaangażowanie."
Modelowanie procesów w ramach systemów SOA Drukuj Email
Ocena użytkowników: / 45
SłabyŚwietny 
Piątek, 02 Maj 2008 14:05

Mający miejsce w ostatnich latach ogromny rozwój technik teleinformatycznych, oraz rosnąca kultura zarządcza i projektowa organizacji sprawiła, że modelowanie procesów biznesowych oraz związane z nim postrzeganie systemów informacyjnych jako narzędzi wsparcia dla procesów stały się wiodącymi kierunkami w zarządzaniu i informatyzacji przedsiębiorstw. Wraz z rozwojem nowoczesnych technologii informatycznych takich jak J2EE czy Web Services oraz coraz bardziej powszechnym szerokopasmowym dostępem do sieci Internet powstała koncepcja budowania systemów informacyjnych w architekturze opartej o usługi (SOA) jako naturalne dopełnienie tendencji związanych z procesowym zarządzaniem przedsiębiorstwem.

Wprowadzenie 

W ciągu ostatnich 20 lat nastąpił ogromny rozwój technologii nazywanych mianem informacyjnych IT (ang. Information Technology). Informatyzacja przedsiębiorstw przestała być postrzegana jako cel sam w sobie. Samo posiadanie systemu informatycznego nie stanowi obecnie kryterium przewagi nad konkurencją, dlatego coraz większą wagę przykłada się do projektowania i wdrażania systemów informatycznych wspierających kluczowe procesy biznesowe organizacji. Wymaga to zdefiniowania mapy procesów biznesowych przedsiębiorstwa oraz wdrożenia złożonego systemu wspierającego pracę różnych, często bardzo oddalonych od siebie funkcjonalnie jednostek organizacyjnych. Ze względu na informacyjno-komunikacyjny charakter takich systemów nazywane one są coraz częściej systemami informacyjnymi lub systemami IKT (Informacyjno-Komunikacyjne Technologie).

W jednym z ostatnich raportów Hype Cycle analitycy firmy Gartner zaprezentowali 36 kluczowych technologii, które ich zdaniem będą determinować rozwój branży IT w najbliższych latach. Do najważniejszych z nich należą Web 2.0, Real-World-Web i architektura zorientowana na usługi SOA (ang. Service-Oriented Architecture). Jednocześnie analitycy uważają, że wciągu dwóch najbliższych lat aplikacje tworzone w oparciu o usługi udostępniane w ramach systemów SOA zdominują rynek oprogramowania dla firm, wypierając obecnie funkcjonujące aplikacje monolityczne [13].

Ogólna definicja systemu SOA określa go jako „zestaw polis, praktyk i bibliotek, które pozwalają wykorzystać funkcjonalność aplikacji w taki sposób, by można było z niej korzystać jako z zestawu usług, opublikowanych tak, by poziom szczegółowości był dostosowany do potrzeb konsumenta usługi. Publikowane elementy są niezależne od implementacji i stosują pojedynczy, standardowy interfejs” [14]. W praktyce powyższa definicja określa system bądź pojedynczą aplikację widzianą z jej otoczenia. Z punktu widzenia implementacji aplikacji może ona wykorzystywać obecne techniki oraz obiektowe języki programowania. W tym wypadku istotne jest wyposażenie aplikacji w odpowiedni interfejs umożliwiający dostęp do oferowanych przez nią usług przez inne elementy systemu informatycznego zgodne ze standardami SOA.

Podstawy technologiczne do budowania systemów zgodnych z ideą SOA powstały w latach 90 razem z technologią zdalnego wywoływania procedur RPC (ang. Remote Procedure Call) [18]. Technologia ta umożliwiała zdalne wywołanie udostępnionych funkcji poprzez sieć. Możliwość ta była głównie wykorzystywana do wykorzystania mocy obliczeniowej wielu maszyn w celu przyspieszenia czasochłonnych obliczeń. Możliwości wykorzystania RPC do udostępniania usług biznesowych były praktycznie niewykorzystywane. Za pierwsze aplikacje, których idea była zgodna z definicją SOA można uznać aplikacje typu klient-serwer, w których część uruchamiana po stronie serwera udostępniała określony pakiet usług aplikacji klienckiej. Takich aplikacji nie można określić jako zorientowanych na usługi, jednak ich architektura odzwierciedla pewne tendencje, których rozwinięcie doprowadziło do powstania architektury SOA. Rozwój obiektowych języków oprogramowania wspieranych narzędziami RAD (ang. Rapid Application Development) spowodował coraz większą komplikację systemów informatycznych. Idea wielokrotnego wykorzystania tych samych modułów aplikacji sprawiła, że projektanci systemów i programiści skupili się na projektowaniu jak najbardziej uniwersalnych klas i komponentów w celu ich potencjalnego wykorzystania w przyszłości. W praktyce znaczna cześć tych funkcji nie była nigdy wykorzystana. W większości wypadków budowa nowej aplikacji wiązała się z ponownym wdrażaniem komponentów biznesowych, nawet jeśli funkcjonowały już one w organizacji. Technologie wykorzystywane do tworzenia aplikacji wiązały ją z konkretnym środowiskiem oprogramowania, uzależniając programistów od producenta konkretnego środowiska programistycznego.

Technologami, które pozwoliły zmienić sposób podejścia do tworzenia aplikacji, były standard Java2TM Enterprise Edition (J2EE) oraz standard serwisów WWW (ang. Web Services). Na początku standardy te były związane z interakcją B2B (ang. Business To Buisness), jednak dzięki oddzieleniu warstwy implementacyjnej od komunikacyjnej i powszechności protokołu HTTP, wraz ze wzrostem wydajności serwisów WWW zaczęto myśleć o ich wykorzystaniu także w systemach wewnątrz organizacji.

Organizacja widziana procesowo

Według normy PN-EN ISO 9000:2000 proces jest zbiorem działań powiązanych lub wzajemnie oddziałujących, które przekształcają wejścia w wyjścia. Rozszerzając tę definicję na procesy biznesowe można powiedzieć, że procesem jest zespół czynności lub działań, których celem jest osiągnięcie oczekiwanego rezultatu. Rezultat ten jest osiągany poprzez przetworzenie stanu wejścia procesu w stan wyjściowy. Przetworzenie to sterowane jest za pomocą z góry ustalonych reguł. Do osiągnięcia tak określonego rezultatu wymagane są określone zasoby. Definicja ta określana jest terminem ICOM (ang. Input, Control, Output, Mechanism) [26].

Bazując na powyższej definicji procesem biznesowym można nazwać spójny zespół sekwencyjnie realizowanych działań ukierunkowanych na realizację oczekiwań klienta, których celem jest osiągnięcie określonej wartości w postaci produktu. Do wytworzenia produktu wymagane są odpowiednie zasoby, inne produkty oraz zbiór reguł, według których tworzony jest dany produkt. Stanem wejściowym procesu może być materiał czy informacja, przekształcana w jego wyniku w produkt tj. przedmiot, usługę lub informację. Zasobami niezbędnymi do realizacji procesu będą m. in. wyposażenie, metody, wiedza, umiejętności, personel oraz jego kwalifikacje. Będący na wyjściu procesu biznesowego produkt musi dać się opisać, być mierzalny i jednoznaczny.

Z powyższej definicji wynika również, że zrozumienie procesów zachodzących w przedsiębiorstwie jest elementem kluczowym do jego rozwoju i usprawnienia jego działania. Z tego też powodu koncepcja zarządzania przedsiębiorstwem przez zarządzanie jego procesami zyskuje w ostatnim czasie coraz większe uznanie. Pojęcie zarządzania procesowego BPR (ang. Business Process Reengineering) jest wyjaśniane na wiele sposobów. Do najbardziej popularnych definicji należą [20]:

  • analizowanie i projektowanie prac i procesów wewnątrz oraz pomiędzy przedsiębiorstwami (Davenport & Short’94);
  • krytyczna analiza i radykalne przeprojektowanie funkcjonujących procesów w celu osiągnięcia znaczących udoskonaleń we wskaźnikach produkcyjnych (Tang et al.’94); 
  • fundamentalne powtórne przemyślenie rozwiązań produkcyjnych oraz radykalne przeprojektowanie procesów w przedsiębiorstwie w celu uzyskania istotnych postępów w krytycznych, obecnych wskaźników produkcyjnych, takich jak koszty, jakość, usługi czy wydajność (Hammer & Champy’93).

Procesowe zarządzanie organizacją wraz z innymi technikami zarządzania takimi jak zarządzanie przez cele z wykorzystaniem strategicznej karty wyników, zarządzanie kosztami z wykorzystaniem controlingu i metody rachunku kosztów działań ABC (ang. Activity-Based Costing) stanowi obecnie główny nurt zmian w zakresie zarządzania nowoczesnymi firmami [25].

Procesowe podejście do zarządzania organizacją zakłada gruntowną analizę procesów na styku organizacji i jej otoczenia jak również zachodzących wewnątrz organizacji [1].

Sposób modelowania procesów biznesowych wynika z czterech podstawowych poziomów opisu organizacji [1]. Najwyższy poziom definiuje strategię firmy. Na tym poziomie określane są działania, których realizacja pozwoli na osiągnięcie założonego celu biznesowego. Poziom koncepcji biznesowej określa, w jaki sposób ma być realizowana strategia firmy. Realizacja koncepcji biznesowej osadzona w organizacji określa, jakimi środkami (zasobami) będą realizowane zadania określone w strategii i koncepcji biznesowej. Dopiero najniższy poziom określa realizację koncepcji biznesowej na poziomie procesów. Z powyższej hierarchii wynika, że niemożliwe jest procesowe podejście do zarządzania przedsiębiorstwem bez jednoznacznego określenia strategii i koncepcji biznesowej. 

Modelowanie procesów biznesowych dostarcza odpowiedzi na pytania dotyczące działania organizacji oraz procesów realizowanych podczas tych działań. W dalszej kolejności możliwa jest odpowiedź na pytanie, czy realizowane procesy są zgodne ze strategią firmy oraz czy jest możliwe ich usprawnienie.

Głównym celem modelowania jest zrozumienie, w jaki sposób funkcjonuje przedsiębiorstwo, a także przeanalizowanie jego działania oraz zaproponowanie możliwych usprawnień. Przejście na zarządzanie procesowe pozwala firmom na stopniowe uaktywnianie pracowników poprzez przypisywanie im roli właścicieli procesów oraz na maksymalne wykorzystywanie ich potencjału.

Głównymi korzyściami płynącymi z modelowania procesów dla każdej organizacji są między innymi [23]:

  • jednolity opis działania przedsiębiorstwa, w którym poszczególni uczestnicy procesu poznają zasady jego funkcjonowania oraz swoją w nim rolę,
  • umożliwienie wdrożenia precyzyjnych mechanizmów śledzenia postępu prac oraz czynników odpowiedzialnych za dany etap procesu,
  • ustalenie optymalnego pod względem czasu, zasobów i kosztów sposobu funkcjonowania przedsiębiorstwa,
  • standaryzacja wykonywanych czynności,
  • usprawnienie komunikacji wewnątrz firmy,
  • stworzenie podstawy do wdrożenia systemu zarządzania jakością zgodnego z wymaganiami ISO 9001:2000,
  • ułatwienie wyboru i efektywnego wdrożenia zintegrowanego systemu wspomagającego zarządzanie przedsiębiorstwem ERP (ang. Enterprise Resource Planning),
  • identyfikacja i klasyfikacja obszarów do usprawnień, pozwalająca na udoskonalenie funkcjonowania przedsiębiorstwa,
  • uporządkowanie realizowanych przez organizację procesów,
  • usprawnienie realizowanych procesów w wymiarach czasowym i finansowym,
  • stałe monitorowanie wyników osiąganych przez poszczególne procesy.

Podczas usprawnienie działania organizacji poprzez modelowanie procesów biznesowych można wyróżnić trzy główne elementy [26]:

  • model biznesowy,
  • mapę procesów biznesowych,
  • mapy przepływu pracy.

Model biznesowy określa powiązania organizacji z jej środowiskiem. W przypadku przedsiębiorstwa będą to jego interakcje z otoczeniem rynkowym. Diagram modelu biznesowego powinien zawierać wszystkie kluczowe podmioty rynku biorące udział w tworzeniu wartości przez firmę jak również przepływy wartości: produktów, pieniędzy i informacji.

Mapa procesów biznesowych to obraz wszystkich funkcji niezbędnych do wytworzenia przez organizację finalnego produktu lub produktów. Finalny produkt może stanowić przedmiot bądź usługa, czyli wszystko, co ma jednoznacznie zdefiniowane cechy i stanowi wartość dla odbiorcy. Mapa procesów powinna być możliwa do zobrazowania przy wykorzystaniu symboliki ICOM. Ze względu na jednoznaczność i obligatoryjność procesów biznesowych na tym etapie nie są modelowane ścieżki decyzyjne.

Sposób realizacji funkcji opisanych przez procesy jest określany przez procedury. Na tym etapie modelowane są ścieżki decyzyjne. W definicji ICOM procedury stanowią wejście sterujące Controls dla procesów.

Projekt modelowania procesów w organizacji można podzielić na kolejne fazy [23, 25]:

  • faza inicjująca,
  • faza identyfikacji i opisu stanu obecnego,
  • faza analizy i optymalizacji procesów,
  • faza opracowania stanu docelowego,
  • faza weryfikacji planu,
  • faza wdrożenia procesów w wersji docelowej.

Czynnikiem sukcesu udanego wdrożenia projektu modelowania i optymalizacji procesów w organizacji jest odpowiednio wysoki poziom świadomości kadry kierowniczej i pracowników. Z tego powodu faza inicjująca powinna obejmować cykl szkoleń dla pracowników przedsiębiorstwa. W kolejnej fazie następuje opracowanie diagramu hierarchii procesów oraz diagramów wątków procesów zidentyfikowanych i aktualnie realizowanych w przedsiębiorstwie. Opis stanu faktycznego stanowi podstawę do usprawniania działania przedsiębiorstwa na bazie optymalizacji istniejących procesów. Zgodnie z filozofią Kaizen podejście ewolucyjne daje większą gwarancję osiągnięcia założonych celów niż zmiany rewolucyjne, dlatego metodologie optymalizacji procesów biznesowych w przedsiębiorstwie zalecają wprowadzanie zmian stopniowo, metodą małych kroków (ang. continous improvement). Podczas fazy identyfikacji i opisu stanu obecnego tworzony jest system mierników procesów oraz określane wskaźniki, jakie powinny zostać osiągnięte przez każdy z wątków procesu. Wskaźnikami mogą być: koszt procesu, czas realizacji procesu, procent wadliwych produktów itp.

Po identyfikacji i opisie istniejących w organizacji procesów następuje faza ich analizy i optymalizacji. Faza ta może być wspomagana narzędziami informatycznymi służącymi do modelowania i optymalizacji procesów. Na tym etapie analizowana jest również zgodność modelu procesów i celów strategicznych organizacji. Zgodnie z cyklem Deminga PDCA (ang. Plan – Do – Check - Act) po fazie analizy i optymalizacji procesów zatwierdzony przez kierownictwo nowy model zostaje wdrożony w organizacji. Po tej fazie możliwy jest powrót do fazy analizy i stopniowe osiąganie optymalnego modelu procesów.

Dobrze opracowany i wdrożony model procesów realizowanych przez daną organizację powinien móc być wykorzystany podczas wdrażania systemu zarządzania jakością jako spełnienie wymagań normy ISO9001:2000 w zakresie punktu 4.1, mówiącego między innymi, że organizacja powinna [19]:

  • zidentyfikować procesy potrzebne w systemu zarządzania jakością i ich zastosowanie w organizacji,
  • określić sekwencję tych procesów i ich wzajemne oddziaływanie,
  • monitorować, mierzyć i analizować te procesy.

Modelowanie procesów znajduje również zastosowanie przy restrukturyzacji przedsiębiorstw jako narzędzie diagnozy zjawisk niepożądanych w funkcjonowaniu organizacji. Wadliwe bądź nieoptymalne procesy, bardziej niż inne elementy organizacji, mogą powodować spadek efektywności i wyników przedsiębiorstwa. W niektórych wypadkach jedynie zrozumienie, a następnie poprawa realizowanych procesów może spowodować ogólne polepszenie kondycji przedsiębiorstwa [23].

Jeszcze jednym sposobem wykorzystania modelu procesów organizacji, jest wsparcie dla wdrożenia dedykowanego systemu informatycznego. Wsparcie to ma szczególne znaczenie podczas projektowania systemu informatycznego opartego o usługi SOA. Dodatkowo, jeśli procesy modelowane są przy wykorzystaniu narzędzi informatycznych, które posiadają wbudowane mechanizmy wymiany danych z narzędziami typu CASE lub systemami klasy ERP, możliwe jest automatyczne wykorzystanie zamodelowanych procesów do opracowania lub wdrożenia systemu informatycznego automatyzującego zdefiniowane sekwencje czynności.

Procesy a systemy informacyjne

Wykorzystanie opisu działania organizacji poprzez zamodelowanie jej procesów biznesowych do zaprojektowania i implementacji dedykowanych systemów informatycznych wspierających działanie organizacji znacznie redukuje ryzyko budowy systemu niespełniającego stawianych przed nim celów. Strukturalność i precyzyjność mapy procesów biznesowych oraz mapy przepływu pracy pozwala przypuszczać, że stworzony w oparciu o nie system informatyczny dla organizacji będzie wspierał realizowane przez organizację procesy biznesowe. Metodyki modelowania procesów pod kątem ich późniejszego wykorzystania do projektowania systemów informatycznych postulują między innymi [23]:

  • identyfikację procesu na podstawie modelu biznesowego i strategii przedsiębiorstwa,
  • wzajemne dostosowanie modelu procesów i strategii
  • automatyzację wyłącznie procesów kluczowych z punktu widzenia realizacji strategicznych celów organizacji,
  • eliminację procesów generycznych, czyli takich, które nie przyczyniają się do realizacji strategii organizacji.

Jak zauważono we wstępie niniejszej pracy, przewagę rynkową nad konkurencją może dać wdrożony i ekonomicznie zasadny system, który ze względu na stawiane przed nim cele można określić mianem informacyjnego. Cele te stają się tożsame z celami analizy, modelowania i optymalizacji procesów biznesowych. Z tego powodu dla systemów informacyjnych są stosowane te same miary jak do analizy procesów biznesowych. Wzajemne przenikanie się koncepcji biznesowej przedsiębiorstwa wspieranej przez procesowe zarządzanie oraz systemów informacyjnych sprawia, że działy informatyki stają się kluczowymi jednostkami organizacji a architekci systemów informacyjnych powinni posiadać wiedzę i kompetencję zarządczą organizacji.

Na rynku rozwiązań IT istnieje wiele narzędzi wspierających modelowanie i optymalizację procesów. Narzędzia te można podzielić ze względu na ich funkcjonalność i przeznaczenie na następujące kategorie [23]:

  • narzędzia wizualizacji graficznej (np. Microsoft Visio),
  • narzędzia mapowania procesów (np. iGrafx FlowCharter),
  • narzędzia modelowania i symulacji procesów (np. iGrafx Process 2000, Corporate Modeler 8e, Aris Toolset, ProcessWise WorkBench, WorkFlow Analyser),
  • narzędzia typu CASE służące do projektowania systemów informatycznych (np. Select Enterprise, Rational Rose),
  • narzędzia modelowania procesów wbudowane w systemy klasy ERP (np. IFS Bussiness Modeler)

Poza wymienionymi zastosowaniami narzędzia do modelowania i optymalizacji procesów można zaklasyfikować ze względu na wspierane funkcje, a w szczególności:

  • możliwości generowania dokumentacji w formacie HTML,
  • kompatybilność z pakietami biurowymi,
  • możliwość wymiany danych z innymi narzędziami i systemami informatycznymi takimi jak systemy ERP, narzędzia CASE, systemy WorkFlow,
  • łatwością i intuicyjnością modelowania procesów,
  • możliwością pracy grupowej,
  • zastosowaniem wybranych notacji.

Wybór konkretnego narzędzia jest ściśle związany z charakterem wykonywanej pracy oraz preferencjami klienta. Narzędzia wizualizacji graficznej takie jak MS Visio są wykorzystywane podczas wizualizacji procesów, w przypadku, kiedy nie jest konieczne przeprowadzanie skomplikowanych symulacji. Narzędzia takie jak ProcessWise i WorkBench są stosowane do przeprowadzania symulacji procesów. W przypadku, gdy konieczne jest szybkie i precyzyjne przeanalizowanie zachodzących procesów oraz zaproponowanie ich usprawnień zastosowanie znajdują zaawansowane narzędzia modelowania i optymalizacji takie jak iGrafx Process.

Architektura zorientowana na usługi

Wymagania stawiane przed systemami IT wspierającymi działanie współczesnych przedsiębiorstw coraz częściej wymagają łączenia technologii różnych dostawców. Konieczność współpracy niekompatybilnych ze sobą systemów i technologii powoduje powstawanie nadmiarowych usług, redundancję danych oraz funkcjonalności. Wraz ze stopniem złożoności wzrasta awaryjność systemów. Najczęściej spotykany obecnie monolityczny model tworzenia aplikacji uzależnia użytkownika od producenta oprogramowania. Ma on do dyspozycji tylko taką funkcjonalność, jaką zaoferuje mu dostawca rozwiązania informatycznego.

 Coraz trudniej też określić granicę, gdzie kończy się system informatyczny jednego przedsiębiorstwa a zaczyna system partnera biznesowego, kooperanta czy klienta. Z punktu widzenia użytkownika systemu ta granica może być całkowicie niedostrzegalna [14]. Z tego powodu systemy informatyczne przedsiębiorstw powinny mieć możliwość wzajemnej komunikacji w oparciu o zrozumiały dla nich protokół.

Z drugiej strony systemy informatyczne wymagają ciągłego dopasowania do zmieniających się potrzeb biznesowych i wymagań klientów. Uważa się, że koszty opieki i modyfikacji systemów wspierających działalność biznesową przedsiębiorstwa sięgają 70% ogólnych kosztów ich utrzymania [10]. Z tego powodu współczesne systemy informatyczne muszą umożliwiać elastyczne wprowadzanie zmian spowodowanych zmieniającymi się założeniami i wymaganiami biznesowymi. Zmiany te powinny być wprowadzane w sposób umożliwiający zachowanie całej niezbędnej istniejącej funkcjonalności. Przestój systemu informatycznego może pociągać za sobą poważne straty zarówno w aspekcie finansowym jak i prestiżowym dla przedsiębiorstwa, dlatego jego rozbudowa powinna odbywać się w sposób nieinwazyjny i bezpieczny dla całości funkcjonowania systemu.

Opisane w poprzednim rozdziale założenia systemu informacyjnego opartego o model procesów biznesowych przedsiębiorstwa pozwalają zaprojektować system precyzyjnie wspierający działalność organizacji zgodnie z jej strategią i koncepcją biznesową. Architekturą, w której tak zaprojektowany system można zrealizować, jednocześnie eliminując problemy integracji oprogramowania pochodzącego od wielu dostawców, zapewniającego wymianę danych i usług pomiędzy podobnymi sobie systemami, zapewniającymi odpowiednią elastyczność i wysoki poziom bezawaryjności jest architektura oparta o usługi SOA.

W ogólnym założeniu architektura SOA opiera się o pojedyncze moduły udostępniające dane, informacje i usługi. Moduły te są nazywane usługami Web (ang. Web Services). Korzystają one z dodatkowych zasobów informatycznych organizacji takich jak bazy danych, zasoby sieciowe inne serwisy niedostępne dla użytkowych aplikacji. Usługi Web przechowywane są abstrakcyjnej warstwie systemowej zwanej zasobnikami (ang. containers)[4, 8]. Zasobnik przechowuje kod serwisu, zarządza jego instancjami oraz zapewnia komunikację z pozostałymi elementami systemu. Usługi udostępniane przez Web Services mogą być zdalnie wywoływane przez programy tworzone w różnych technologiach [10]. Komunikacja pomiędzy elementami systemu odbywa się za pośrednictwem szyny ESB (ang. Enterprise Service Bus). Z szyny ESB korzystają aplikacje systemu SOA, których funkcjonalność wykorzystuje usługi udostępniane przez serwisy Web. Szyna ESB poprzez odpowiedni interfejs służy również do komunikacji z innymi systemami SOA [21].

Standaryzowanie protokołów komunikacyjnych daje możliwość udostępnienia w ramach SOA usług oferowanych przez serwisy różnych producentów oprogramowania. Serwisy te mogą być następnie wykorzystywane do budowania aplikacji wspierających realizację wskazanych procesów biznesowych organizacji.

Dzięki zastosowaniu technologii serwisów WWW aplikacje są uruchamiane w dowolnej przeglądarce internetowej, niezależnie od platformy. Nowoczesne technologie budowania aplikacji WWW, oparte o język Java, JavaScript i servlety, takie jak Google Web Toolkit, umożliwiają tworzenie interfejsu użytkownika o funkcjach, ergonomii i wyglądzie bardzo zbliżonym do aplikacji systemu Windows, łącząc zalety aplikacji typu desktop z możliwościami strony WWW.

W przypadku aplikacji monolitycznych istniejących w organizacji zachodzi konieczność dostosowania ich do systemu pracującego w ramach architektury SOA. Jeśli architektura aplikacji na to pozwala, można to osiągnąć poprzez wymianę warstw dostępu do danych aplikacji na pracujące zgodnie z logiką architektury SOA. Można też, bez wprowadzania dodatkowych zmian w istniejącej aplikacji za pomocą systemu zgodnego ze specyfikacją SOA, umożliwiającego komunikację poprzez szynę ESB, udostępnić jej usługi dla innych aplikacji systemu SOA. W obu wypadkach użytkownicy aplikacji pracują w znanym sobie środowisku bez konieczności zmiany sposobu pracy oraz uczenia nowego systemu informatycznego. Wadą obu rozwiązań jest pozostawienie aplikacji w stanie hermetycznym, z utrudnioną możliwością rozbudowania jej funkcji o nowe usługi udostępniane w ramach systemu SOA. W niektórych wypadkach, szczególnie, gdy aplikacja nie spełnia stawianych przed nią celów wynikających z modelu procesów biznesowych, należy rozważyć konieczność jej ponownej implementacji wykorzystując technologie dostępne w ramach SOA. Można również przypuszczać, że w przypadku rozwoju systemów SOA, aplikacje monolityczne integrowane w ramach tych systemów będą stopniowo zastępowane usługami i aplikacjami zgodnymi z logiką architektury zorientowanej na usługi

Z informatycznego punktu widzenia tworzenie aplikacji w architekturze SOA jest zadaniem trudnym. Wdrożenie systemu opartego o usługi może wiązać się z kosztami przewyższającymi rozwiązania oparte o tradycyjne technologie i architekturę. Korzyści z wprowadzenia systemu o architekturze SOA mogą być widoczne w dalszej perspektywie jego eksploatacji.

Rozwój standardów związanych z architekturą SOA i usługami Web jest monitorowany przez instytucję The Web Services Interoperability Organization (WS-I). Organizacja ta skupia z jednej strony najbardziej liczących się producentów związanych z usługami Web, takich jak BEA, IBM, Microsoft, jak również małe firmy programistyczne oraz podmioty zainteresowane wdrażaniem i używaniem technologii SOA. Działalność WS-I nie kończy się jedynie na określaniu specyfikacji. Organizacja gwarantuje, że produkty dowolnych producentów korzystających ze standardu będą mogły bezproblemowo współpracować ze sobą na zasadzie wymiany informacji. Opracowany przez WS-I profil podstawowy usług Web obejmuje bazowe usługi w warstwie komunikacyjnej. Obecnie prace organizacji koncentrują się na tworzeniu elementów infrastruktury usług Web, które pozwoliłyby odwzorować skomplikowane mechanizmy komunikacji biznesowej.

Podstawą protokołu komunikacyjnego jest niezależny od platformy język XML (ang. eXtensible Markup Language) XML będący podzbiorem języka SGML (ang. Standard Generalized Markup Language) [7]. Do zarządzania danymi XML stosuje się obiektowe modele danych XML DOM (ang. Data Object Model). Wbudowane w XML DOM parsery pozwalają z dokumentu tekstowego uzyskać łatwe do przetwarzania i nawigacji struktury danych. Udostępniane w XML DOM mechanizmy pozwalają na wyszukiwanie, edycję oraz wizualizację danych w obrębie jednego bądź wielu dokumentów XML. Dzięki standaryzowaniu składni języka XML dokument poprawny składniowo może być przetwarzany przez XML DOM dowolnego producenta. O ile na poziomie API każdy XML DOM może dysponować inną składnią i zakresem funkcji, to będące na wejściu i wyjściu dokumenty XML są zgodne z leksyką języka [7].

Dokument XML w modelu danych XML jest reprezentowany przez hierarchiczną strukturę węzłów XML (ang. XML nodes). Węzły zawierające elementy tekstowe, atrybuty, oraz inne węzły nazywane są elementami XML (ang. XML elements). Węzłem nadrzędnym dla całej struktury jest dokument XML (ang. XML dokument) zawierający jeden element główny (ang. document element). Większość XML DOM pozwala na zadawanie zapytań do dokumentu XML przy wykorzystaniu składni XSL (ang. eXtensible Stylesheet Language) – XQuery (ang. XML Query Language). Wynikiem zapytania XQuery jest lista węzłów XML spełniających warunki zapytania. Dokumenty XML mogą być transformowane za pomocą przekształceń XSLT (ang. XSL Transformations) oraz wizualizowane poprzez szablony XSL nazywane niekiedy XSL-FO (ang. XSL Formatting Objects). Wszystkie te mechanizmy sprawiają, że język XML doskonale nadaje się do przekazywania danych, dokumentów, komunikatów o nieokreślonej lecz usystematyzowanej strukturze. Jego zastosowanie w najniższej warstwie komunikacyjnej pozwala osiągnąć elastyczność i niezależność od platformy czy też producenta oprogramowania niezbędną do uzyskania przy założonym modelu architektury SOA.

Usługami bazowymi zdefiniowanymi przez WS-I są:

  • SOAP (ang. Simple Object Access Protocol) – oparty o XML protokół dostępu do obiektów (klas) umożliwiający zdalne wywołanie metod klasy wyposażonej w interfejs SOAP. Komunikacja między klientem a serwerem SOAP odbywa się poprzez protokół HTTP.
  • WSDL (ang. Web Services Description Language) – oparty o XML opisujący protokoły i formaty usług Web.
  • UDDI (ang. Universal Description, Discovery and Integration) – inicjatywa mająca na celu stworzenie uniwersalnego rejestru usług Web. W swoim założeniu UDDI ma umożliwić automatyczne wykrycie i integrację usługi Web w sieci Internet.

Elementami architektury SOA będącymi w opracowaniu przez WS-I są obecnie [14]:

  • WS-Policy i WS-Secutity Policy – standardy definiujące zasady działania usług Web,
  • WS-Adressing – technologia umożliwiająca warunkowe przekierowanie wywołania usługi,
  • WS-Eventing – realizowany w modelu subskrybująco-publikującym z wykorzystaniem technologii „push” standard realizujący odpowiednik zdarzeń systemowych w aplikacjach desktopowych,
  • Message Transmission Optimization Mechanizm – protokół umożliwiający przesyłanie dużych ilości danych poprzez rozbijanie ich na mniejsze pakiety.

Organizacja WS-I zatwierdziła język BPEL (ang. Business Process Execution Language), który pozwala modelować procesy biznesowe, łącząc poszczególne usługi. W chwili obecnej trudno jednoznacznie określić, które elementy architektury SOA opisane przez WS-I są już standardami przemysłowymi. Dla użytkowników najważniejszy jest zdefiniowany w profilu podstawowym zestaw usług, w oparciu o który można już budować aplikacje.

Modelowanie procesów a SOA

System stworzony w architekturze SOA dostarcza jako funkcjonalność końcową odbiorcy szereg bardziej lub mniej złożonych usług. Jeżeli system ten ma stanowić wsparcie zarządzania przedsiębiorstwem, przed jego zaprojektowaniem należy zidentyfikować, zamodelować oraz zoptymalizować procesy kluczowe dla organizacji, eliminując przy tym procesy generyczne. Tylko takie podejście da możliwość zidentyfikowania usług, jakie mają być realizowane w ramach systemu informatycznego [2].

Podczas projektowania systemu informatycznego następuje przejście od procesu biznesowego do usług niezbędnych do jego realizacji wspieranych przez odpowiednie funkcje systemu. Następuje tym samym automatyzacja kluczowych dla przedsiębiorstwa procesów biznesowych. Cykl życia systemu SOA składa się z czterech podstawowych elementów: planowania, implementacji, udostępnienia i zarządzania. Z tego punktu widzenia system SOA można podzielić na trzy warstwy: procesów biznesowych, wynikających z tych procesów usług oraz warstwy infrastruktury informatycznej [5] (rys. 8). Cykl życia polega na nieustannej interakcji pomiędzy tymi warstwami wynikającymi z dostosowania usług do modelu biznesowego organizacji, infrastruktury informatycznej do usług, usuwania błędów w fazie modelowania i implementacji, zmiany wymagań biznesowych.

Identyfikację procesów biznesowych organizacji można zrealizować stosując podejście oparte na encjach [1]. Podejście to identyfikuje procesy na podstawie odpowiedzi na pytania dotyczące podstawy działania organizacji na rynku (EBE – ang. Essential Business Entity), działań, które nie są wymagane przez rynek, ale są wynikiem podjęcia przez organizację decyzji o określonym sposobie funkcjonowania (DBE – ang. Designed Business Entity) oraz określenia działań prowadzących do udostępnienia produktów oraz usług oferowanych przez organizację (UOW – ang. Unit of Work). Wykorzystując to podejście należy udzielić odpowiedzi na pytania:

  • Co organizacja wytwarza?
  • Co organizacja sprzedaje?
  • Jakie usługi oferuje?
  • Z jakimi klientami zewnętrznymi i wewnętrznymi współpracuje?
  • Na jakie wydarzenia musi reagować?
  • Jakie informacje są przechowywane w systemach informatycznych?

Na podstawie odpowiedzi na te i podobne pytania określane są procesy kluczowe dla działania organizacji, oraz produkty (przedmioty, usługi lub informacje) wytwarzane przez te procesy. Na tej podstawie można dokonać wyboru procesów, których automatyzacja pozwoli na poprawienie funkcjonowania przedsiębiorstwa. Procesy te mogą zostać następnie zdekomponowane na pakiety usług i zaimplementowane przez dostawców różnych elementów zintegrowanego systemu informatycznego. Dzięki temu w systemie informatycznym wyeliminowane zostaną dane oraz usługi dublujące się w kilku procesach biznesowych. Usługa zapewniająca dostęp do bazy kontrahentów będzie mogła być wykorzystywana przez moduł finansowo-księgowy jak również przez oprogramowanie stanowiące wsparcie dla procesów działu marketingu czy serwisu. Architektura SOA gwarantuje, że dostawcy oprogramowania będą mogli korzystać z usług już dostępnych w ramach systemu.

Idea automatyzacji procesów przy wykorzystaniu architektury SOA za punkt wyjścia stawia właśnie model procesów. Na podstawie analizy organizacji są identyfikowane i modelowane procesy wynikające ze strategii i koncepcji biznesowej organizacji. Procesy te zostały zdekomponowane na usługi służące do ich realizacji. Podczas dekompozycji wykazano usługi wspólne dla obu procesów. Zaprojektowany system informatyczny wspomagający procesowe zarządzanie przedsiębiorstwem składa się z pakietu usług służących do realizacji zidentyfikowanych kluczowych procesów biznesowych oraz aplikacji automatyzujących te procesy wykorzystujących usługi. Dzięki architekturze SOA możliwe jest wielokrotne wykorzystanie usług wspólnych dla procesów w systemach automatyzacji. Komunikację pomiędzy usługami a aplikacjami automatyzującymi procesy zapewnia szyna ESB.

Z powyższego przykładu wynika, że nie można oddzielić architektury SOA od modelu procesów biznesowych organizacji. Koncepcja SOA polega na ścisłym związku biznesu z informatyką: warstwa usług powinna odwzorowywać istotę działalności biznesowej. Dlatego SOA wymaga analizy procesów biznesowych, prowadzącej do określenia listy usług IT przez kluczowych użytkowników biznesowych. W koncepcji podejścia procesowego do wdrożeń IT informatyka pełni rolę gwaranta efektywności procesów [16].

Literatura

[1]        AION Sp. z o.o. Modelowanie procesów biznesowych, Materiały prezentacyjne, Politechnika Wrocławska Centrum Kształcenia Ustawicznego, 2-3.12.2006
[2]        Bieberstein N. et al., Impact of service-oriented architecture on enterprise systems, organizational structures, and individuals, IBM System Journal, vol. 44, no. 4, 2005, pp. 691 – 708
[3]        BPMI.org, Object Management Group, Business Process Modeling Notation (BPMN) Specification, http://www.bpmn.org/ 
[4]        Brown K., Reinitz R., Web Services Architectures and Best Practices, IBM WebSphere Developer Technical Journal (2003),
http://www-128.ibm.com/developerworks/websphere/techjournal/0310_brown/brown.html 
[5]        Cox D. E., Kreger H., Management of the service-oriented architecture life cycle, IBM System Journal, vol. 44, no. 4, 2005, pp. 709 – 726
[6]        Dałkowski B., Hołodnik K., Podstawy zarządzania projektami. Analiza projektu, Get Manager 2006., Materiały prezentacyjne, Politechnika Wrocławska Centrum Kształcenia Ustawicznego
[7]        Erl T., Service-Oriented Architecture, Pearson Education, Inc. Pentice Hall PTR, New Jersey, 2004
[
8]        Ferguson D. F., Stockton M. L., Service-oriented architecture: Programming model and product architecture, IBM System Journal, vol. 44, no. 4, 2005, pp. 753 – 780
[9]        Frączkowski K., Zarządzanie projektem informatycznym. Projekty w środowisku wirtualnym. Czynniki sukcesu i niepowodzeń projektów, Oficyna Wydawnicza Politechniki Wrocławskiej, Wrocław, 2003
[10]     Frączkowski K., Mazur Z., SOA – architektura zorientowana na usługi, Bazy Danych, nr 7, Oficyna Wydawnicza Politechniki Wrocławskiej, Wrocław, 2006
[11]     Główny Instytut Górnictwa, Przewodnik ISO 9000. Materiały informacyjne nt. wdrażania systemu zarządzania jakością wg norm ISO serii 9000 : 2000, Katowice, 2004, http://www.mgip.gov.pl
[12]     IDS-Sheer Polska Spółka z o.o., 10 kroków do wdrożenia SOA, http://www.ids-scheer.pl , 2006
[13]     IDS-Sheer Polska Spółka z o.o., Technologie IT przesądzające o kierunkach rozwoju branży IT w przyszłości, według raportu Gartnera, http://www.ids-scheer.pl , 2006
[14]     Kopacz T., Świat jako usługa, Computerworld, 30-2004
[15]     Majdan K, Zarządzanie procesowe w organizacjach RTD, Gazeta Innowacje nr 14 2002, http://www.gazetainnowacje.pl
[16]     MSI Polska, ARIS ProcessDay, http://www.msipolska.pl
[17]     Muszyński J., Borland: narzędzia modelowania dla SOA, Serwery Computerworld, http://serwery.computerworld.pl/news/98839.html , 09.2006
[18]     Paluśkiewicz  M., SOA na co dzień, Infovide, http://www.infovide.pl/docs/M_Paluskiewicz_SOA.pdf , Warszawa, 2004
[19]     PN-EN ISO 9001:2001: Systemy Zarządzania Jakością. Wymagania. Polski Komitet Normalizacyjny, Warszawa 2001
[20]     Quality Progress, Zarządzanie procesowe BPR, http://www.qualityprogress.com.pl , 2004
[21]     Schmidt M.-T. et al., The Enterprise Service Bus: Making service-oriented architecture real, IBM System Journal, vol. 44, no. 4, 2005, pp. 781 – 797
[22]     Szyjewski Z., Metodyki zarządzania projektami informatycznymi, Wydawnictwo Placet, Warszawa, 2004
[23]     Wróbel M., Modelowanie procesów biznesowych jako narzędzie doskonalenia organizacji, Centrum Rozwiązań Menedżerskich S.A., Warszawa, http://www.crm.com.pl/wiedza2.htm
[24]     White S., Using BPMN to Model a BPEL Process, IBM Corp., United States, http://www.bpmn.org/
[25]     Zawistowski T, Procesowe zarządzanie organizacją, Problemy Jakości, nr 09.2001, http://www.umbrella.org.pl
[26]     Żeleński J., Modelowanie procesów biznesowych, czyli pilnowanie hochsztaplerów, IT-Consulting, 2005, http://www.egospodarka.pl/

 


Zmieniony ( Piątek, 02 Maj 2008 14:54 )
 

Dodaj swój komentarz

Twoje imię:
Temat:
Komentarz:

Użytkownicy

Naszą witrynę przegląda teraz 4 gości 

Google

RSS

 PManager.pl RSS 

Obecnie oglądasz:  Strona główna Procesy biznesowe Modelowanie procesów w ramach systemów SOA