o modelowaniu procesów i systemów 

Budowa modelu architektury biznesowej w dużym uproszczeniu polega na następujących etapach:

1. Określenie strategicznych celów organizacji
2. Budowa modelu biznesu na wysokim poziomie abstrakcji
3. Znalezienie ram strukturalnych organizacji
4. Budowa modelu procesu biznesowego

IMHO powyższe punkty zasadniczo nie odbiegają od standardowej ścieżki budowy modeli procesów biznesowych a czasem wymagań na system. Różnica polega na tym, że architektura korporacyjna swoim zasięgiem obejmuje więcej, szerszy kontekst działania organizacji, niż tradycyjny model biznesowy.

W zeszłym roku pisałem w tekście pt. Architektura korporacyjna bardzo ogólnie o architekturze korporacyjnej. Teraz postaram się w kilku słowach napisać o jej zaletach.

• Architektura korporacyjna pozwala na uporządkowanie portfela posiadanych systemów informatycznych i rozwiązań technologicznych.
• Znajomość zasobów aktualnych zasobów IT i procesów biznesowych z nich korzystających (as-is) pozwala zaplanować rozwiązania do celowe (as-will).
• Dzięki architekturze korporacyjnej łatwiej jest przedstawić działanie poszczególnych systemów informatycznych przekłada się na funkcjonowanie procesów biznesowych.
• IMHO najważniejsze: Architektura korporacyjna ułatwia rozbudowę i optymalizację funkcjonalności informatycznych, gdyż przedstawia aplikacje, systemy i platformy, które są powiązane złożoną siecią wzajemnych zależności.

Innymi słowy każda organizacja powinna budować taką architekturę, gdyż to daje jej możliwość elastycznego rozwoju. Co więcej budowa “tradycyjnych modeli biznesowych jest podstawą do budowy architektury korporacyjnej.

Dużo się mówi na temat modelowania systemów informatycznych w języku UML. A co z systemami, które nie są informatycznymi? Za nim odpowiem na to pytanie warto przypomnieć sobie czym jest system a pomoże mi w tym zestawienie jakie zrobił Robert Gwiazdowski, którego pozwalam sobie zacytować:

Pod pojęciem systemu nauka rozumie zintegrowaną całość, której własności nie są prostą sumą własności poszczególnych części tej całości, istnienie jednak szereg związków i interakcji pomiędzy nimi. (E. Laszlo, Systemowy obraz świata, Warszawa 1978; L. von Bertalanffy, Ogólna teoria systemów, Warszawa 1984) „Doniosłą cechą systemów jest tkwiący w samej ich istocie charakter dynamiczny. Systemy pod względem formy nie są sztywnymi strukturami; ich forma wyraża zmienne, a jednocześnie trwałe przejawy procesów zachodzących w systemach”. (F. Capra, Punkt zwrotny, Warszawa 1987) Funkcjonowanie systemu stanowi rezultat zachodzących w nich pętli sprzężeń zwrotnych polegających na tym, że element A oddziaływa na element B, B na C, zaś C zwrotnie na A. W systemie nie działa linearny łańcuch przyczyn i skutków, lecz zjawisko nielinearnej współzależności.

Z powyższych definicji wynika, że system składa się ze struktur, które zmieniają swój stan – przejawiają zachowanie. Jest to wspólna cecha systemów informatycznych (np.: struktura: klasa, zachowanie metoda, która zmienia stan klasy) i systemów nieinformatycznych (np.: struktura: siłownik, zachowanie: uruchomienie dźwigni, która zmienia położenie – stan  -siłownika).

Reasumując skoro UML nadaje sie do modelowania systemów informatycznych to nadaje się także do modelowania wszystkich innych typów systemów ze szczególnym  naciskiem na automatykę i robotykę.  Nie można też zapomnieć o innych dziedzinach społecznych nie związanych z informatyką, gdzie są stosowane różnej maści systemy (np.: system wynagrodzeń). W obszarach nietechnicznych UML sprawdza się bardzo dobrze przy modelowaniu procesów biznesowych, gdzie także możemy odnotować, że (cytując R. Gwiazdowskiego)  element A oddziaływa na element B, B na C, zaś C zwrotnie na A. Co w konsekwencji pozwala sądzić, że w modelach biznesowych (ponownie cyt.) nie działa linearny łańcuch przyczyn i skutków, lecz zjawisko nielinearnej współzależności.

Pojęcie architektury korporacyjnej (ang. enterprise architecture )  zaczyna funkcjonować w świadomości co raz to większej liczby firm. Firmy te dostrzegły potrzebę opisania struktury i współpracy na poziomie komponentów. Tymi komponentami mogą być pracownicy firmy, działy firm, systemy informatyczne.

Koncepcją, która może pomóc zmienić postrzeganie informatyki w urzędzie – z roli czysto technicznej, na mającą istotne znaczenie dla funkcjonowania jednostki – jest architektura korporacyjna (enterprise architecture). W literaturze definiuje się ją jako opis struktury i funkcji komponentów jednostki (komponentami są np. ludzie, procesy biznesowe, struktury organizacyjne jak również systemy informatyczne), wzajemnych powiązań pomiędzy tymi komponentami oraz pryncypiów i wytycznych zarządzających ich tworzeniem i rozwojem w czasie. Czyli mówimy tutaj nie tylko o modelach, ale także o sposobie działania.

Dla mnie architektura korporacyjna jest modelem biznesowym na wysokim poziomie abstrakcji. Znamiennym jest iż budując architekturę korporacyjną można skorzystać z modele koncepcyjnych (EA Framework) takich jak:

• Zachman Framework
• FEAF (Federal Enterprise Architecture Framework)
• DoDAF (Department of Defense Architecture Framework)
• TOGAF (Open Group Architecture Framework)
• Meta Group (obecnie Gartner)

Moją ulubioną “strategią” budowania architektury korporacyjnej jest TOGAF (The Open Group Architecture Framework) nie tylko, ze najlepiej go z nam, ale także dlatego, że jest to podejście rekomendowane przez UE.

Z racji tego, że publikacja odnośnie zwinnego podejścia w zakresie modelowania procesów biznesowych (WMB) –pisałem o tym kilka dni temu w tekście pt “Krajowa Konferencja Inżynierii Oprogramowania“- ukazała się w limitowanej edycji 150 egzemplarzy pozwalam sobie na publikację skanu tego tekstu.

W tym miejscu pozwolę sobie zebrać kilka cech, które świadczą o tym, że mamy do czynienia z dobrym modelem biznesowych przypadków użycia. Oto one:

• Biznesowe przypadki użycia są zrównane ze strategią firmy – wspierają cele organizacji.
• Przypadki użycia są zgodne z organizacją, którą opisują.
• Wszystkie przypadki użycia są znalezione. Po zebraniu, przypadki użycia wykonują wszystkie zadania w ramach organizacji.
• Każde zadanie w ramach organizacji jest ujęte w przynajmniej jednym Przypadku Użycia.
• Istnieje równowaga między liczbą przypadków użycia a ich wielkością:
• Model zawiera kilka przypadków użycia  – przez co jest łatwiejszy do zrozumienia.
• Przypadek użycia opisuje pełen przepływ informacji, który produkuje coś wartościowego dla klienta.
• Każdy przypadek użycia jest unikatowy. Jeżeli przepływ informacji jest taki sam lub podobne do innego przypadku użycia, trudno będzie utrzymać je później w zsynchronizowaniu. Należy uwzględnić scalenie je w pojedynczy przypadek użycia.

Ile z podanych cech spełniają Twoje modele?

Budowanie modeli biznesowych coraz częściej znajduje uznanie wśród projektantów systemów. Wiąże się to z faktem, że modele biznesowe stanowią podstawę całego przedsięwzięcia bowiem pozostałe dyscypliny inżynierii oprogramowania (bazując teraz na dyscyplinach RUP )czerpią z niej w następujący sposób:

• Dyscyplina Wymagania wykorzystuje biznesowe modele jako istotne dane wejściowe dla zrozumienia wymagań systemu.
• Dyscyplina Analiza i Projekt wykorzystuje biznesowe modele jako dane wejściowe dla określenia systemów oprogramowania, które płynnie pasują do organizacji.
• Dyscyplina Wdrożenia wykorzystuje biznesowe modele jako pomoc w planowaniu zastosowaniu systemu oprogramowania.

Co więcej modelowanie biznesu jest procesem iteracyjnym, który zaczynając kawałek po kawałku, w każdej iteracji, pozwala nam na na lepsze poznanie organizacji a tym samym dostarczenia istotnych treści dla procesu wytwórczego oprogramowania.

Celem modelowania biznesu jest:

• Zrozumienie bieżących problemów w docelowej organizacji i określenie potencjałów udoskonalenia.
• cena wpływu zmiany organizacyjnej.
• Zapewnienie, że klienci, użytkownicy, inwestorzy oraz inne strony będą rozumieć organizację w ten sam sposób.
• Wyprowadzenie wymagań systemu oprogramowania, które jest konieczne, aby wspierać docelową organizację.
• Zrozumienie jak system oprogramowania, który ma być wykorzystywany w przyszłości, wpasuje się w organizację.

Schemat organizacyjny nie jest wystarczający, aby zrozumieć działanie firmy. Potrzebujemy również dynamicznego widoku przedsiębiorstwa. Model biznesowy zapewnia statyczny widok konstrukcji organizacji i dynamiczny widok procesów w obrębie organizacji.

Dla mnie to bardzo ważne  gdyż tylko dzięki widokom z różnych perspektyw (statycznej i dynamicznej) jestem wstanie poprawnie zaprezentować na modelu jak nowy system będzie wspierał organizację.

Aby przewidzieć wymogi dla aplikacji biznesowej można rozważyć stworzenie następujących modeli:

• Schemat proceduralny interfejsu użytkownika. Dostarcza on przeglądu ekranów i raportów oraz to, jak w jaki sposób są one wzajemnie powiązane. Na chwilę obecną potrzebujesz jedynie głównych ekranów i raportów. 
• Diagram WPA (Wysokiego Poziomu Abstrakcji). Diagram procesu wysokiego poziomy, plus kilka diagramów dających podgląd kilku krytycznych procesów, są zazwyczaj potrzebne do zrozumienia przepływu biznesowego.
• Diagramy przypadków użycia. Zamiast diagramów procesu wysokiego poziomu (WPA) możesz zrobić diagram przypadków użycia wysokiego poziomu. Jest to kwestia tego preferencji, ja prawdopodobnie nie robiłbym tego diagramu, gdyż WPA jest dla mnie wystarczający.
• Diagram klas. Wskazuje na nim ważne dane, które są przetwarzane w organizacji.
• Diagram procesu. Czyli popularny diagram aktywności.  Warto na nim zamieścić obiekty.
• Definicje słownikowe. Być może będziesz chciał zacząć od zidentyfikowania kluczowych terminów biznesowych. Widziałem zbyt wiele zespołów uziemionych przez „paraliż analizy” ponieważ próbowali zdefiniować dokładną terminologię przed przejściem do następnych etapów. Nie wpadnij w tę pułapkę.

Podane punkty stanowią składową wielu aplikacji biznesowych, ale w zależności od specyfiki biznesu i procesu niektóre z nich mogą być opcjonalne.

Największym kapitałem każdej organizacji są zachodzące w niej procesy. Aby procesy te mogły być efektywnie doskonalone należy je w odpowiedni sposób odwzorować w systemie informatycznym. Zanim przystąpi się do budowy systemu informatycznego warto dobrze poznać te procesy budując ich modele. Dziś przyszłość stanowią metodyki zwinne (Agile) w tym także te, które wykorzystują modele. Właśnie tej tematyce  – zwinnemu modelowaniu procesów biznesowych poświęcone było dwudniowe szkolenie, jakie miałem przyjemność poprowadzić 23-24 lipca w Warszawie.

Jedna z warszawskich firm w tym nurcie będzie modelować procesy biznesowe celem dostarczania klientom dedykowanych rozwiązań, które opierają się na otwartym kodzie tworzonej aplikacji. Pozwala to by aplikacja ta była w przyszłości rozwijana i modyfikowana przez dowolny podmiot, nie wyłączając oczywiście samego użytkownika.

Szkolenie przebiegło w bardzo dobrej, twórczej atmosferze. Otrzymałem tylko dobre i bardzo dobre noty a w komentarzach w pozycji Co najbardziej podobało Ci się na szkoleniu można przeczytać między innymi: “skupienie się prowadzącego na sednie sprawy”, “praktyczne przedstawienie złożonego tematu…”. Dziękuję

 Kilka dni temu pisałem (patrz Modelowanie Procesów Biznesowych – BPM 2009), o moim wystąpieniu na konferencji BPM w trakcie, którego proponowałem podejście do modelowania procesów biznesowych w języku UML. Moja propozycja ukierunkowana była na nurt Agile i zalety jakie on niesie dla biznesu. Nie chodzi tu o legendarny brak dokumentacji i inne stereotypy dotyczące nurtu Agile (patrz m.in. Zwinne modelownie – mity i fakty). W moim rozumieniu modelowanie Agile to przede wszystkim rozważne modelowanie procesów biznesowych w trakcie którego, będąc ukierunkowanym na zmiany i potrzeby klienta, nie traci się zalet, jakie niesie wizualizacja procesu biznesowego w języku UML.   Moje poglądy podziela  Jacek Kołodziejak Dyrektor ds. Rozwoju w firmie Intertrading Systems Technology Sp. z o.o, który na konferencji Gigacon ISI 2009 (2 czerwca 2009) mówił o zaletach platformy JBoss Enterprise Middleware. Wygląda na to, że obaj zgadzamy się, iż zastosowanie metodyk zwinnych w modelowania biznesowym, pozwalają na zwiększenie elastyczności biznesowej a tym samym szybsze reagowanie na potrzeby biznesu co w konsekwencji pozwala na doskonalenie procesu biznesowego i zwiększanie wartości dodanej firmy.   Co więcej zastosowanie wizualizacji procesów biznesowych za pomocą języka UML pozwala na identyfikację zbioru wzajemnie przeplatających się procesów. Innymi słowy:

podejście Agile + modelowanie w UML = zwiększenie elastyczności biznesowej

Na koniec dziękuję za wymienienie mojej osoby w trakcie prezentacji. Cała prezentacja jest dostępna pod adresem http://www.rejestracja.software.com.pl/download/6853.html

Pod hasłem WMB gromadzić będę zestawy wskazówek pozwalające na dokumentację procesów biznesowych. Celem WMB nie jest tylko ułatwienie budowy modeli biznesowych, ale także rozszerzenie notacji UML o stereotypy, które pozwalają na budowę bardziej jednoznacznych modeli.

WMB to:

• aktywności – jako wskazówki do działania – zestawy czynności warunkujące osiągnięcie poprawnego modelu
• role  – jako zakres kompetencji dla osób wykonujących model biznesowy,
• notacja UML – jako rozszerzenie notacji UML o stereotypy, które pozwalają na budowę bardziej jednoznacznych modeli,
• rozszerzenia narzędzi CASE -  jako profile pozwalające na budowę modeli biznesowych z wykorzystaniem notacji WMB

przeczytaj pozostałą część »

Wikipedii nikomu nie trzeba przedstawiać. Pewną ciekawostką, zwłaszcza dla zwolenników BMPN, jest wpis dot. modelowania procesów biznesowych. Pod hasłem Business Process Modeling w rozdziale Modeling and simulation można przeczytać, że diagramami do modelowania procesów biznesowych są: diagram przypadków użycia i diagram aktywności (dowód na rysunku poniżej)

Na szczęści twórca tego wpisu nie zapomniał o technikach modelowania procesów biznesowych, gdzie można znaleźć pozostałe diagramy