Wykład 8 Przepływ prac: Modelowanie biznesowe

Prezentacja na temat: "Wykład 8 Przepływ prac: Modelowanie biznesowe"— Zapis prezentacji:

1 Wykład 8 Przepływ prac: Modelowanie biznesowe
Polsko-Japońska Wyższa Szkoła Technik Komputerowych Warszawa Studia Podyplomowe IT w Biznesie Rational Unified Process Wykład 8 Przepływ prac: Modelowanie biznesowe Wykładowca: dr inż. Ewa Stemposz

2 Zagadnienia Zagadnienia Zagadnienia
Modelowanie biznesowe: cele i efekty Modelowanie biznesowe - czy warto? Rodzaje modelowania biznesowego Notacja Pracownicy i artefakty Przepływ prac Od modelu biznesowego do systemu Inne źródła wymagań na system Wsparcie narzędziowe Podsumowanie Prezentowany materiał został przygotowany w oparciu o publikację: Philippe Kruchten, The Rational Unified Process An Introduction, Addison-Wesley, 1999.

3 Modelowanie biznesowe: cele i efekty
Modelowanie biznesowe - pierwszy z głównych przepływów prac - powinno poprzedzać proces specyfikowania wymagań na oprogramowanie (przepływ prac: Wymagania). Cele: Ułatwienie zrozumienia struktury i dynamiki organizacji, w której oprogramowanie ma być wdrażane (tzw. “organizacji docelowej”). Ułatwienie zrozumienia aktualnych problemów organizacji w celu zidentyfikowania miejsc dla potencjalnych ulepszeń. Uzyskanie pewności, że wszyscy uczestnicy projektu (klienci, użytkownicy i członkowie zespołu projektowego) postrzegają docelową organizację w jednakowy sposób (jej strukturę, dynamikę i problemy). Utworzenie bazy dla specyfikowania wymagań na oprogramowanie. Efekty: Uzyskanie wizji “nowej organizacji docelowej” i w oparciu o nią zdefiniowanie procesów, ról i odpowiedzialności w organizacji.

4 Modelowanie biznesowe - czy warto ? (1)
Oprogramowanie musi być “intuicyjnie dopasowane do miejsca”, w którym będzie wykorzystywane, bo stanowi narzędzie codziennego użytku (zarówno w pracy, jak i w domu). Oprogramowanie przestało być gadżetem wytwarzanym przez „czarodziei komputerowych” dla hobbystów. Dlatego, w proces tworzenia modelu biznesowego powinien być wciągany każdy pracownik organizacji dla której tworzone jest oprogramowanie: od członków zarządu i marketingu po szeregowych pracowników włącznie. Wciąganie pracowników organizacji w proces tworzenia modelu biznesowego, jest uważane obecnie za bardziej efektywne podejście do specyfikowania wymagań na oprogramowanie, niż korzystanie z porad ekspertów dziedzinowych. Eksperci dziedzinowi mają wiedzę, ale brak im władzy niezbędnej do wprowadzania zmian w organizacji, zmian będących efektem automatyzowania jej działalności.

5 Modelowanie biznesowe - czy warto ? (2)
Nie każde przedsięwzięcie, związane z produkowaniem software’u, wymaga przeprowadzania modelowania biznesowego. Wydaje się, że warto przeprowadzać modelowanie biznesowe w sytuacji, gdy więcej informacji musi być obsługiwanych przez system, czyli np. gdy większa grupa ludzi ma być bezpośrednimi użytkownikami danego systemu. Np. rozszerzenie istniejącego systemu o kilka dodatkowych cech z reguły nie wymaga budowy modelu biznesowego, ponieważ zasadnicze cele systemu nie ulegają radykalnej zmianie. Sytuacja wygląda inaczej, gdy trzeba zbudować system nie na półkę, ale na zamówienie konkretnego klienta, ponadto wspierający prace w organizacji, gdzie procesy biznesowe są złożone. Właściwa realizacja projektu wymaga tu pełnej świadomości skutków automatyzacji prac: innymi słowy trzeba dobrze zrozumieć, jak automatyzacja wpłynie na zmianę reguł prowadzenia biznesu.

6 Modelowanie biznesowe - czy warto ? (3)
Potrzeba modelowania biznesowego jest wyraźnie widoczna dla organizacji tworzących software dla e-biznes’u - modelowanie biznesowe zajmuje tu centralne miejsce w procesach realizacji projektów. E-biznes - nowy buzz word - biznes związany z tworzeniem aplikacji (zwanych czasami narzędziami biznesowymi) wspomagających automatyzację procesów biznesowych. Można wyróżnić tu: C2B (Customer to Business): aplikacje wspomagające współpracę klienta z firmą, np. zakupy przez Internet. B2B (Business to Business): automatyzacja współpracy między firmami, np. automatyzacja łańcucha dostaw. B2C (Business to Customer): dostarczanie informacji do klienta (klient jest tu stroną bierną), np. rozsyłanie biuletynów informacyjnych. C2C (Customer to Customer): automatyzacja wymiany informacji między klientami, z niewielkim wsparciem ze strony providera, np. aukcje internetowe.

7 Rodzaje modelowania biznesowego (1)
Inżynieria biznesowa może być realizowana mniejszym lub większym wysiłkiem w zależności od konkretnego kontekstu i potrzeb. Można tu wyróżnić sześć postawowych scenariuszy: (1) Mapa organizacji: Można zbudować prostą mapę organizacji i jej procesów, w celu osiągnięcia dobrego zrozumienia wymagań na budowany system. W takim wypadku modelowanie biznesowe jest częścią realizowanego projektu i z reguły ma miejsce w fazie początkowej. (2) Modelowanie dziedziny: Jeśli głównym zadaniem budowanego systemu jest prezentacja i zarządzanie informacją (np. system wspierający zarządzanie zamówieniami czy system bankowy), można zbudować model informacji na poziomie biznesowym. Odpowiada to modelowaniu dziedziny w inżynierii oprogramowania, z reguły wykonywanym w fazach początkowej i opracowywania. (3) Jeden biznes, wiele systemów: Jeśli budowany jest duży system (rodzina aplikacji) można przeprowadzić modelowanie biznesowe, którego rezultaty zostaną wykorzystane w kilku projektach. Model biznesowy posłuży do specyfikowania wymagań funkcjonalnych i architektury.

8 Rodzaje modelowania biznesowego (2)
(4) Generyczny model biznesowy: Jeśli budowany jest system, który będzie wykorzystywany przez kilka organizacji (np. system wspierający sprzedaż czy rozliczenia rachunkowe) może być użyteczne zbudowanie generycznego modelu biznesowego. Pozwoli to na uszeregowanie organizacji w zależności od ich reguł biznesowych (aby uniknąć specyfikowania zbyt złożonych wymagań) lub pomoże zrozumieć i zarządzać różnicami, jakie w tych regułach występują, co z kolei powinno ułatwić przypisywanie priorytetów wymaganiom na system. (5) Nowy biznes: Jeśli organizacja decyduje się na rozpoczęcie zupełnie nowej linii biznesu, dla której wsparcie ma stanowić budowany system - modelowanie biznesowe jest konieczne. Model biznesowy ma nie tylko wspomóc specyfikowanie wymagań na system, ale też pozwolić na oszacowanie wykonalności nowego przedsięwzięcia. W takim wypadku modelowanie biznesowe jest z reguły przeprowadzane w postaci oddzielnego projektu. (6) Reorganizacja (reinżynieria procesów biznesowych): Jeśli organizacja decyduje się na kompletną przebudowę procesów, modelowanie biznesowe z reguły staje się zadaniem dla co najmniej kilku projektów.

9 Notacja Techniki wykorzystywane w modelowaniu biznesowym są podobne do technik inżynierii oprogramowania, a nawet historycznie rzecz biorąc: techniki, które zostały wypracowane przez inżynierię oprogramowania stanowiły inspirację dla rozwoju nowych dróg w wizualizowaniu organizacji. Ponieważ modelowanie oparte o podejście obiektowe stanowi podstawę rozwoju większości projektów związanych z produkcją oprogramowania, wykorzystywanie podobnych technik w modelowaniu biznesowym wydaje się być naturalnym rozwiązaniem. Notacja Użytkownicy biznesowi - zewnętrzni w stosunku do biznesu, jak np. klienci, sprzedawcy czy partnerzy - są reprezentowani przez aktorów biznesowych. Procesy biznesowe są reprezentowane przez biznesowe przypadki użycia i biznesowe realizacje przypadków użycia. Pracownicy biznesowi reprezentują role, jakie ludzie odgrywają wewnątrz organizacji. Encje biznesowe reprezentują artefakty, które organizacja produkuje lub którymi zarządza.

10 Pracownicy i artefakty (1)
Biznesowy model przypadków użycia Słownik biznesowy Reguły biznesowe Biznesowy model obiektowy Analityk procesów biznesowych Oszacowanie organizacji docelowej Wizja biznesu Dokument architektury biznesowej Uzupełniająca specyfikacja biznesu

11 Pracownicy i artefakty (2)
Realizacja biznesowego przypadku użycia Biznesowy przypadek użycia Aktor biznesowy Projektant biznesowy Encja biznesowa Jednostka organizacyjna Pracownik biznesowy

12 Pracownicy i artefakty (2)
Pracownicy zaangażowani w modelowanie biznesowe Najważniejsi to: analityk procesów biznesowych i projektant biznesowy. Analityk procesów biznesowych: Rodzaj przewodnika i koordynatora w procesie modelowania biznesowego - do jego zadań należy ustanowienie wizji nowego biznesu, określenie aktorów biznesowych, biznesowych przypadków użycia oraz interakcji między nimi. Projektant biznesowy: Uszczegóławia specyfikację części organizacji przez dostarczenie opisu relewantnych biznesowych przypadków użycia. Określa pracowników biznesowych i encje biznesowe niezbędne do realizacji przypadków. Ponadto, definiuje odpowiedzialności, atrybuty, operacje i zależności między pracownikami biznesowymi a encjami biznesowymi. Inni pracownicy: np. dostarczający informacji czy zaangażowani w przeglądy ( np. recenzent biznesowy).

13 Pracownicy i artefakty (3)
Najważniejsze artefakty: Dokument wizji biznesu: specyfikuje cel prac związanych z modelowaniem biznesowym. Biznesowy model przypadków użycia: specyfikuje użytkowników biznesowych oraz funkcje (procesy) biznesowe, w oparciu o które zostaną zidentyfikowani pracownicy biznesowi i encje biznesowe. Biznesowy model obiektowy: model obiektowy specyfikujący realizację biznesowych przypadków użycia w terminach oddziaływania pracowników biznesowych na encje biznesowe. Biznesowy model obiektowy powstaje przy użyciu tych samych technik modelowania, co model obiektowy systemu, tyle że na wyższym poziomie abstrakcji. Np. klasa na poziomie biznesowym reprezentuje odpowiedzialności nie w systemie, ale w organizacji.

14 Pracownicy i artefakty (4)
Inne artefakty: Oszacowanie docelowej organizacji: zawiera ocenę aktualnego stanu organizacji. Reguły biznesowe: specyfikują reguły polityki prowadzonej przez organizację i ograniczenia, które muszą być wypełniane. Uzupełniająca specyfikacja biznesu: zawiera definicje nie ujęte ani w biznesowym modelu przypadków użycia ani w biznesowym modelu obiektowym. Słownik biznesowy: zawiera definicje pojęć biznesowych. Jednostka organizacyjna: zgrupowanie pracowników i encji biznesowych, w celu odzwierciedlenia struktury organizacji (np. w celu uwidocznienia istnienia departamentów). Mechanizm grupowania pozwala ponadto na zrównoleglenie struktury modelu przypadków użycia i modelu projektowego.

15 Przepływ prac (1) [Inne rodzaje modelowania] [Pełne modelowanie biznesowe] [Początek opracowywania] Szacuj statusu organizacji Identyfikuj procesy biznesowe Opisz aktualny biznes Badaj możliwości automatyzacji procesów [Tylko modelowanie dziedziny] Ulepsz (refine) procesy biznesowe Możliwych jest kilka ścieżek w zależności od celu modelowania biznesowego. Modeluj dziedzinę Projektuj realizację procesów biznesowych Ulepsz role i odpowiedzialności

16 Przepływ prac (2) W pierwszej iteracji należy oszacować status organizacji docelowej - tej, w której system ma być wdrażany. Główne artefakty, które powinny tu powstać to: Oszacowanie organizacji docelowej i Wizja biznesu. Bazując na rezultatach oszacowania, należy wybrać któryś z omówionych wcześniej scenariuszy modelowania biznesowego. Jeśli nie zachodzi potrzeba wprowadzania dużych zmian do istniejących procesów biznesowych, wystarczy wybrać scenariusz 1-szy, tzw. „Mapę organizacji” (skupienie uwagi na wymaganiach na system, a nie na ulepszaniu procesów biznesowych). Jeśli nie jest potrzebne przeprowadzenie “pełnego modelowania biznesowego” wybiera się scenariusz 2-gi, tzw. “Modelowanie dziedziny”. Model dziedzinowy jest traktowany w RUP jako podzbiór obiektowego modelu biznesowego - podzbiór zawierający wyłącznie encje biznesowe. Jeśli potrzeba ulepszyć procesy biznesowe lub przeprowadzić reinżynierię procesów biznesowych należy wybrać scenariusze 3-ci, 4-ty i 6-ty. Jeśli planowane jest rozpoczęcie nowego biznesu, należy wybrać scenariusz 5-ty z ominięciem aktywności: Opisz aktualny biznes.

17 Od modelu biznesowego do systemu (1)
Biznesowy model obiektowy model przypadków użycia Modelowanie biznesowe X O K Model przypadków użycia Model projektowy Model implementacji Model testowy Modelowanie systemu

18 Od modelu biznesowego do systemu (2)
Klient Biznesowy model przypadków użycia Transakcja pieniężna Biznesowy model obiektowy :Klient :Specjalista d.s. kredytów :Profil klienta :Konto :Kredyt :Urzędnik Transakcja pieniężna 1 Transakcja pieniężna 2 [System] Model przypadków użycia Urzędnik Specjalista d.s. kredytów

19 Od modelu biznesowego do systemu (3)
Aktorów systemu, jak i systemowe przypadki użycia można wyprowadzać z modelu biznesowego. Pracownikowi biznesowemu przyporządkowywuje się relewantnego aktora w systemie, a biznesowemu przypadkowi użycia, w którym pracownik biznesowy uczestniczy - relewantny systemowy przypadek użycia. Jeśli celem jest budowa systemu, który ma całkowicie zautomatyzować procesy biznesowe (jak np. e-biznes), proces przyporządkowywania przebiega inaczej. Transakcja pieniężna Klient Biznesowy model przypadków użycia :Klient :Urzędnik :Specjalista d.s. kredytów Biznesowy model obiektowy :Profil klienta :Konto :Kredyt

20 Od modelu biznesowego do systemu (4)
Biznesowy model obiektowy :Klient :Specjalista d.s. kredytów :Profil klienta :Konto :Kredyt :Urzędnik Krok 1 [System] Model przypadków użycia Transakcja pieniężna 1 Transakcja pieniężna 2 Urzędnik Specjalista d.s. kredytów Krok 2 Transakcja pieniężna 1 Transakcja pieniężna 2 [System] Model przypadków użycia Klient Specjalista d.s. kredytów

21 Od modelu biznesowego do systemu (5)
Odpowiedzialności związane z pracownikami biznesowymi zostają przeniesione na aktorów systemowych. Encje biznesowe - z kolei - są kandydatami na obiekty klas w systemie. :Klient :Urzędnik :Specjalista d.s. kredytów Biznesowy model obiektowy :Profil klienta :Konto :Kredyt Model analityczny Profil klienta Konto Kredyt

22 Od modelu biznesowego do systemu (6)
Automatyzacja procesów biznesowych może pociągać za sobą zmianę modelu biznesowego: każdy pracownik biznesowy i każda encja powinny być implementowane przez jeden rodzaj zasobów. Biznesowy model obiektowy :Klient :Specjalista d.s. kredytów :Urzędnik Biznesowy model obiektowy :Automatyczny Urzędnik :Automatyczny specjalista d.s. kredytów :Specjalista d.s. kredytów :Klient

23 Inne źródła wymagań na system
Inne - nie ujęte w modelu biznesowym - źródła informacji wspomagające pozyskiwanie wymagań na projektowany system : użytkownicy, nie reprezentowani w modelu biznesowym, np. administrator systemu, strategie obowiązujące w biznesie poddawanym analizie, związane np. z technologiami informacyjnymi, ponownym użyciem, kompatybilnością i jakością, wszelkie rzeczy spadkowe, ograniczenia czasowe (w tym koordynacja z innymi równolegle prowadzonymi projektami), aktualne trendy obowiązujące zarówno w dziedzinie związanej z rozważanym biznesem, jak i w dziedzinie związanej z technologiami informacyjnymi.

24 Wsparcie narzędziowe; Podsumowanie
Narzędzia, wspierające proces modelowania biznesowego, dostarczane przez RUP: Rational Rose: do wizualizacji opisanych wcześniej modeli biznesowych; używane są te same pojęcia UML, które służą do budowy modeli dla projektowanego systemu z nieco innymi stereotypami. Rational RequisitePro: do zarządzania zależnościami występującymi między elementami zawartymi zarówno w tym samym modelu, jak i w różnych modelach. Rational SoDa: do generowania i zarządzania dokumentacją powstającą w trakcie modelowania biznesowego. Modelowanie biznesowe jest szczególnie użyteczne przy budowie: systemów dedykowanych, np. dla jednej lub kilku organizacji w pewnej dziedzinie: bankowość, ubezpieczenia, itp., rodziny aplikacji przeznaczonych na rynek, np.: systemy do obsługi zamówień, systemy bilingowe, systemy do kontroli ruchu powietrznego, itp.