Laboratorium z zarządzania procesami biznesowymi

Transkrypt

1 Katedra Informatyki Gospodarczej Szkoła Główna Handlowa Laboratorium z zarządzania procesami biznesowymi dr Andrzej Sobczak

2 Agenda spotkania Sprawdzamy pracę domową Jak zastosować podejście procesowe przy wdraŝaniu IT Dwa słowa nt.: czym jest UML czym jest RUP UML w modelowaniu biznesowym Zamiast podsumowania... 2

3 Katedra Informatyki Gospodarczej Szkoła Główna Handlowa Sprawdzamy pracę domową

4 Katedra Informatyki Gospodarczej Szkoła Główna Handlowa Jak zastosować podejście procesowe przy wdraŝaniu IT

5 Jak zastosować procesy biznesowe przy wdraŝaniu IT Analiza kontekstu biznesowego Analiza istniejących procesów Klasyfikacja procesów Opis procesów Identyfikacja usprawnień Opracowanie specyfikacji wymagań dla rozwiązań IT Model wymagań biznesowych Wybór kierunku rozwoju IT System z z półkip ki Implemen- tacja 5

6 Analiza kontekstu biznesowego Obszar biznesu Na czym firma chce budować wartość, co ma decydować o jej przewadze konkurencyjnej? - cena - oferta produktowa - jakość obsługi W jakim zakresie firma ma być pionierem a w jakim naśladowcą? W jakim zakresie poszczególne obszary działalności powinny być zróŝnicowane ze względu na produkty? Czy obsługa i wymiana informacji z klientami, dostawcami ma dokonywać się w sposób elektroniczny? Jaki stopień dynamiki oraz zakres zmian przewidywany jest w poszczególnych obszarach? Obszar IT Jakie są priorytety wdroŝenia rozwiązań w poszczególnych procesach? W jakim zakresie zastosowanie rozwiązań IT powinno mieć standardowy (rozwiązanie z półki ), a w jakim unikatowy ( skrojony na miarę ) charakter? Jaki zakres rozwiązań IT powinien być wspólny, a jaki zróŝnicowany na produkty? Jakie są wymagane standardy bezpieczeństwa oraz standardy wymiany danych z otoczeniem? Jaki jest wymagany zakres elastyczności systemu na zmiany? 6

7 Klasyfikacja procesów Podejście do klasyfikacji procesów: Top down wstępna klasyfikacja, przed rozpoczęciem opracowania map procesów Bottom up klasyfikacja procesów po dokonaniu analizy powiązań pomiędzy działaniami Określenie zdarzeń/podmiotów inicjujących procesy oraz końcowych rezultatów/odbiorców produktów PrzełoŜenie zdarzeń/rezultatów na procesy - łączenie działań wg ciągów przyczynowo-skutkowych Zachowanie rozłączności procesów Określenie priorytetów procesów Dostosowanie poziomu szczegółowości opisu procesów do ich priorytetów oraz wymaganego poziomu standaryzacji Przyjęcie kilku wzorcowych (2-3) jednostek organizacyjnych dla opracowania modelu 7

8 Opis procesów Wykorzystanie umownej notacji dla przedstawienia: zdarzeń inicjujących proces rezultatów procesu działań (zróŝnicowanych na manualne oraz zautomatyzowane: dialogowe, wsadowe) przebiegu procesu (z wyodrębnionym elektronicznym przepływem danych) z uwzględnieniem wyjątków oraz alternatywnych ścieŝek Rozszerzenie opisu działań o następujące elementy: wymagane kontrole powiązania z dokumentacją wykorzystywaną w procesie powiązania z jednostkami organizacyjnymi, w których działania są realizowane powiązania z aktualnie wykorzystywanymi systemami informatycznymi Określenie parametrów procesów: czas realizacji koszt realizacji liczba zaangaŝowanych etatów częstotliwość zdarzeń w procesach liczba jednostek obsługiwanych w procesach liczba błędów występujących w procesach 8

9 Identyfikacja usprawnień Ocena jakości procesów biznesowych Określenie przyczyn, dla których procesy biznesowe nie dostarczają oczekiwanych rezultatów Identyfikacja słabych punktów w procesach wynikających z braku bądź nieefektywności rozwiązań IT Określenie usprawnień, których wdroŝenie jest moŝliwe dzięki rozwiązaniom IT Wyodrębnienie w modelu procesów wszystkich działań, które: są obecnie zautomatyzowane, jednakŝe wymagają uzupełnienia bądź migracji do nowego rozwiązania powinny zostać zautomatyzowane: przekształcenie danych w działaniach moŝna opisać algorytmem działania są kluczowe dla realizacji procesu (efektywność, jakość, ryzyko operacyjne) działania są realizowane często i/lub są złoŝone są stabilne ze względu na zmiany Określenie przebiegu procesów po wdroŝeniu usprawnień Oszacowanie korzyści/oszczędności wynikające z wdroŝenia rozwiązań IT Określenie priorytetów dla wdroŝenia rozwiązań IT w róŝnych obszarach realizacji procesów 9

10 Opracowanie specyfikacji wymagań Model wymagań biznesowych System z półki Implementacja Proces wyboru i dostosowania oprogramowania Model obiektów Model procesów Model koncepcyjny Projekt bazy Model techniczny Projekt modułów 10

11 Modelowanie biznesowe 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). Ma to znaczenie, gdy trzeba zbudować system 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. 11

12 Model wymagań biznesowych Model procesów biznesowych uwzględniający usprawnienia Opisuje sposób wykorzystania systemów informatycznych z punktu widzenia uŝytkownika: przeznaczenie systemu zakres działań realizowanych przez system opis interakcji z uŝytkownikami, innymi systemami, podmiotami zewnętrznymi Jest uzupełniony o oczekiwane wartości mierników efektywnościowych Określa wymagania funkcjonalne oraz informacyjne wynikające z potrzeby: modyfikacji istniejących systemów wdroŝenia nowych systemów Określa wymagania w zakresie integracji systemów: dostęp do wspólnych baz danych zbudowanie interfejsów wymiany danych 12

13 Wybór kierunku rozwoju systemu IT proces system Czy dostosować system do procesu czy proces do systemu? Czy procesy, czy rozwiązania technologiczne stanowią o przewadze konkurencyjnej? Jaki jest stopień dopasowania pomiędzy rozwaŝanym rozwiązaniem IT oraz istniejącymi potrzebami biznesowymi? Koszt? Czas trwania wdroŝenia? Zakres zmian w procesach, systemach IT? Ryzyko niepowodzenia wdroŝenia? Jak rozwiązanie wpływa na relacje z otoczeniem? 13

14 Budować czy kupić? System implementowany od początku Proces stanowi o przewadze konkurencyjnej W procesach o specyfice, dla której brak wsparcia w systemach z półki Nakłady dostosowania systemu z półki przewyŝszają nakłady implementacji systemu od początku Wymaga bardzo szczegółowej specyfikacji wymagań uŝytkowników Wysokie ryzyko niepowodzenia wdroŝenia? System z półki Proces standardowy DuŜa presja czasu na wdroŝenie Systemy IT posiadają wystarczający zakres parametryzacji w ramach istniejącej funkcjonalności Wysoki poziom niezawodności MoŜliwość rozbudowy oraz integracji w istniejącym środowisku informatycznym Oddalenie się od osiągnięcia głównych czynników stanowiących o przewadze konkurencyjnej Opór przed wdroŝeniem zmian do procesów Trudności w integracji w istniejącej infrastrukturze technologicznej Niewykorzystanie pełnej funkcjonalności standardowego oprogramowania 14

15 System z półki Analiza luk pomiędzy wymaganiami biznesowymi a istniejącą funkcjonalnością systemu Określenie moŝliwości parametryzacji systemu lub określenie zakresu zmian wymaganych w procesach Przygotowanie szczegółowej specyfikacji w zakresie uzupełnienia luki pomiędzy istniejącą, a wymaganą funkcjonalnością systemów Analiza nakładającej się funkcjonalności pomiędzy róŝnymi aplikacjami Określenie moŝliwości integracji aplikacji z innymi systemami Specyfikacja wymaganych interfejsów pomiędzy systemami 15

16 Implementacja Model obiektów obejmuje: wyodrębnione obiekty biznesowe, które są przedmiotem działań realizowanych w procesie atrybuty opisujące poszczególne obiekty Model procesów obejmuje: zdarzenia, które inicjują proces sekwencje działań wykonywanych przez poszczególne jednostki organizacyjne zakres informacji powiązania z obiektami - wykorzystywanych (będących na wejściu/wyjściu) w procesie oraz jego poszczególnych działań operacje na obiektach: utworzenie, odczyt, modyfikacja, usunięcie reguły i/lub warunki wykonania operacji na obiektach zdefiniowane za pomocą sformalizowanych algorytmów reguły kontroli danych interakcje w procesie z uŝytkownikami z innymi procesami Wymagania pozafunkcjonalne: Wydajność Bezpieczeństwo Rozszerzalność Otwartość 16

17 Problemy z procesami Stworzone przez zamkniętą w przedsiębiorstwie grupę ludzi Nierealistyczne podejście Niska świadomość pracowników Lęk przed poraŝką Mnogość notacji 17

18 Dwa słowa nt.: - czym jest UML - czym jest RUP Katedra Informatyki Gospodarczej Szkoła Główna Handlowa

19 Cele stworzenia UML Wizualny język modelowania do budowy i wymiany modeli. Silny mechanizm rozbudowy. Wykorzystywany przy tworzeniu systemów informatycznych NiezaleŜny od języków programowania i procesów tworzenia. Wspomaga wysoko-poziomowe rozwiązania. 19

20 Początki UML (1a) Na przełomie lat 80-tych i 90-tych pojawiło się ponad 50 róŝnorodnych metodyk obiektowych m.in. Booch, OMT, OOSE/Objectory, Fusion, Coad/Yourdon. Poszczególni twórcy próbowali wykazać wyŝszość własnego rozwiązania nad pozostałymi, co niekorzystnie wpływało na przemysłowe próby zastosowania technologii obiektowych. KaŜda metodologia miała własną notację, otrzymywała wsparcie ze strony róŝnych narzędzi programistycznych, obejmowała róŝny zakres projektowania systemu informatycznego. 20

21 Początki UML (5) UML OMT SA/RT ERD JSD SADT Merise DFD DFD etc. 21

22 UML wprowadza zestaw standardowych diagramów Use Use Case Case Diagrams Use Use Case Case Diagrams Activity Activity Diagrams Diagrams Use Use Case Case Diagrams Use Use Case Diagrams Use Use Case Case Diagrams Diagrams State Diagrams State State Diagrams Class Class Diagrams Diagrams State Diagrams State State Diagrams Object Object Diagrams Diagrams Scenario Diagrams Scenario Scenario Diagrams Sequence Sequence Diagrams Diagrams Model State Diagrams State Diagrams State State Diagrams Diagrams Scenario Diagrams Scenario Collaboration Scenario Diagrams Diagrams Diagrams Deployment Diagram Diagram Component Component Diagrams Component Diagrams Component Diagrams Diagrams Component Diagrams Diagrams 22

23 Czym jest RUP (Rational Unified Process) RUP jest procesem (wytwórczym) inŝynierii oprogramowania, którego celem jest zapewnienie produkcji wysokiej jakości oprogramowania z przewidywalnym budŝetem i harmonogramem, które spełni oczekiwania uŝytkowników końcowych. RUP reprezentuje dyscyplinarne podejście przypisujące zadania i obowiązki wewnątrz zespołu. RUP jest konfigurowalnym procesem, poniewaŝŝaden pojedynczy proces nie jest odpowiedni do wytworzenia kaŝdej aplikacji. W ten sposób istnieje moŝliwość dostosowania procesu do rozmaitych sytuacji. RUP jest produktem rozwijanym i utrzymywanym przez firmę IBM opartym na doświadczeniu w pracy z wieloma klientami firmy. RUP jest przewodnikiem jak skutecznie uŝywać UML a. 23

24 RUP - Rational Unified Process Oś pionowa reprezentuje statyczne aspekty (zawartość) procesu; opisuje proces pod względem działań, artefaktów, pracowników (ang. workers) oraz przepływu zadań (ang. workflow). Inicjacja - Rozwijanie Konstruowanie -WdroŜenie Przekazanie Oś pozioma reprezentuje czas i przedstawia dynamiczne aspekty procesu uŝywając pojęć: cykli, faz, iteracji oraz kamieni milowych (ang. milestones). Proces tworzenia oprogramowania podzielony jest na cykle, gdzie kaŝdy cykl reprezentuje tworzenie nowej generacji (wydania) produktu. 24

25 Iteracje w RUP KaŜda faza RUP moŝe zostać podzielona na iteracje. Iteracja jest kompletną pętlą tworzenia pewnej części finalnego produktu, który przyrasta inkrementalnie z jednej iteracji na drugą tworząc ostatecznie końcowy system. Korzyści podejścia iteracyjnego: łatwiejsze zaŝegnanie elementów ryzyka, większa zarządzalność zmianami, moŝliwość nauki zespołu projektowego w trakcie projektu, lepsza całkowita jakość, 25

26 Fazy Ŝycia w RUP a diagramy UML Zamiast skupiać się na produkcji duŝej ilości papierowych dokumentów RUP kładzie większy nacisk na tworzenie semantycznie bardziej treściwych modeli. 26

27 Składniki RUP (1) Role i ich aktywności 27

28 Składniki RUP (2) Artefakty Szablony 28

29 Składniki RUP (4) Koncepcje (metody postępowania) Przepływy pracy ( krok po kroku ) 29

30 Przepływ pracy: inŝynieria wymagań Develop Vision Manage Dependencies Elicit Stakeholder Needs Find Actors and Use Cases Capture a Common Vocabulary Structure the Use-Case Model Requirements Reviewer Use-Case Specifier Detail a Use Case Review Requirements User-Interface Designer User-Interface Modeling User-Interface Prototyping Architect Prioritize Use Cases 30

31 Przepływ pracy: analiza i projektowanie Architectural Analysis Architect Architectural Design Describe Concurrency Describe Distribution Review the Architecture Architecture Reviewer Designer Use-Case Analysis SubsystemDesign Use-Case Design Review the Design Design Reviewer Class Design Database Designer Database Design 31

32 Przepływ pracy: implementacja Architect Structure the Implementation Model System Integrator Plan System Integration Integrate System Implementer Plan Subsystem Integration Implement Classes Perform Unit Test Integrate Subsystem Fix a Defect Code Reviewer Review Code 32

33 Przepływ pracy: testy Test Designer PlanTest Design Test ImplementTest Evaluate Test Integration Tester Execute Integration Test System Tester Execute System Test Performance Tester Execute Performance Test Designer Design Test Classes and Packages Implementer Implement Test Components and Subsystems 33

34 Składniki RUP (5) Produkty informatyczne 34

35 Katedra Informatyki Gospodarczej Szkoła Główna Handlowa UML w modelowaniu biznesowym

36 ZałoŜenia Struktura organizacji nie jest wystarczająca do zrozumienia jak funkcjonują jej procesy biznesowe. Niezbędne jest tu dynamiczne spojrzenie na biznes. Modelowanie biznesu umoŝliwia zlokalizowanie problemów lub zidentyfikowanie moŝliwości wprowadzenia ulepszeń do procesów zachodzących w organizacji. 36

37 Modelowanie biznesowe (1) Cele modelowania od strony organizacji: Zrozumienie bieŝących problemów danej organizacji i identyfikacja moŝliwości ulepszenia zachodzących procesów biznesowych. Ocena wpływu zmian organizacyjnych. Zapewnienie, Ŝe klienci, końcowi uŝytkownicy i inni jednakowo rozumieją organizację pod kątem zachodzących w niej procesów biznesowych. Wskazanie wymagań na utworzenie oprogramowania niezbędnego dla wsparcia procesów biznesowych danej organizacji. 37

38 Modelowanie biznesowe (2) Cele modelowania od strony systemu informatycznego: Czy wszystkie wymagania (systemowe przypadki uŝycia) dla budowanego systemu informatycznego zostały zidentyfikowane? Jak pracownicy organizacji realizują procesy biznesowe organizacji przed wprowadzeniem systemu informatycznego? Jaką wartość wniesie system do biznesu? Jak będzie wyglądał biznes, gdy system informatyczny będzie go wspierał? 38

39 Proces modelowania biznesowego 39

40 Notacja UML w modelowaniu biznesowym UŜycie jednakowej notacji oraz narzędzi do modelowania biznesu oraz systemu umoŝliwia analitykom biznesowym oraz analitykom systemowym lepsze przedstawienie swoich potrzeb, co stanowi klucz do budowy systemu, który rozwiązuje problemy klientów. 40

41 Æ Á ¹ ¼- ëçñ º ±â»ç ëàú äã»çñ Ù. È-ÀÏ ü ÀÚ Â Àоî  ¹ ¼-ÀÇ Á º ÇØ ç ¹ ¼- ü ¼³Á À» äã»çñ Ù. È- é ü  ÀоîµéÀΠüµé ëçø ÀÌ º Î Á ÄÀ» ½ÃÄÑ È- é º ÁØ Ù. 1: Doc view request ( ) 1: Doc view request ( ) 9: sortbyname ( ) 2: fetchdoc( ) L 3: create ( ) 6: filldocument ( ) 9: sortbyname ( ) 2: fetchdoc( ) 7: readfile ( ) 5: readdoc ( ) 4: create ( ) 8: fillfile ( ) 5: readdoc ( ) 7: readfile ( ) 4: create ( ) 8: fillfile ( ) 3: create ( ) 6: filldocument ( ) FileMgr fetchdoc( ) sortbyname( ) rep Repository (from Persistence) name : char * = 0 readdoc( ) readfile( ) UI DocumentApp Persistence FileList add( ) delete( ) File read( ) DocumentList add( ) delete( ) flist 1 GrpFile read( ) open( ) create( ) fillfile( ) Document name : int docid : int numfield : int get( ) open( ) close( ) read( ) sortfilelist( ) create( ) filldocument( ) global MFC RogueWave read() fill the code.. Openning Reading add file [ numberoffile==max ] / flag OFF close file Closing close file add file Writing ºÐ»ê È æàç Çϵå þ¾î¹ ³ Æ À ÎÀÇ Á º ½Ã½ºÅÛ á ðµ - À µµ ì 95 : Å óàì¾ðæ - À µµ ì NT: ÀÀ ë¼-¹ö - À нº Ó½Å: ÀÀ ë ¼-¹ö ¹ µ ÀÌÅ ¼-¹ö, Åë½Å ¼-¹ö - IBM ÞÀÎÇÁ ¹ÀÓ: µ ÀÌÅ ¼-¹ö, Åë½Å ¼-¹ö Window95 ¹ ¼- ü Å óàì¾ðæ.exe Windows NT Windows NT ¹ ¼- ü Áø.EXE Windows95 IBM Mainf rame µ ÀÌÅ º À̽º¼-¹ö Solaris ÀÀ ë¼-¹ö.exe Windows95 ¹ ¼- ü ¾ÖÇà Alpha UNIX UML jak to działa? BOM, Business Use-Case Diagram, Class Diagram Use-Case Diagram Actor A Use Case 1 Actor B State Diagram Ekspert dziedzinowy Use Case 2 Use Case 3 <<entity>> Customer name addr receive() withdraw() fetch() send() Class Deployment Diagram Repository DocumentList user :»ç ëàú mainwnd : MainWnd filemgr : FileMgr gfile : GrpFile Package Diagram FileManager GraphicFile File Document FileList repository : Repository mainwnd filemgr : document : gfile repository user FileMgr Document document : Document Collaboration Diagram Component Diagram Forward Engineering(Code Generation) and Reverse Engineering Sequence Diagram SYSTEM 41

42 UML jak to działa? Pierwszym krokiem w modelowaniu biznesu jest zdefiniowanie interakcji pomiędzy jednostkami na zewnątrz biznesu (dostawcy, klienci partnerzy, inne wydziały, itd.) a procesami biznesowymi organizacji. Interakcja jest dokumentowana w Diagramach Biznesowych Przypadków UŜycia. Diagramy wizualnie przedstawiają interakcję pomiędzy głównymi usługami które organizacja dostarcza a tymi, dla których usługi są dostarczane (Business Actors). 42

43 Business Use Case Model Model Biznesowych przypadków uŝycia The processes of a business are defined as a number of different business use cases, each of which represents a specific workflow in the business. A business use case defines what should happen in the business when it is performed. Określa jak przedsiębiorstwo reaguje na klienta lub zdarzenie UŜywany do identyfikacji aktorów i procesów biznesowych Zewnętrzne spojrzenie na planowane procesy biznesowe 43

44 Business Use Case Model Biznesowych przypadków uŝycia Aktor (na zewnątrz organizacji) Proces biznesowy 44

45 Model Biznesowych przypadków uŝycia - dekompozycja 45

46 Business Object Model A Business Object Model defines the business use cases from the business workers internal viewpoint. The model defines how people who work in the business, and the things they handle and use Składniki BOM: Business workers pracownik biznesowy Business entities 46

47 Business Object Model Business workers reprezentuje stanowisko powołane w organizacji Business entities reprezentuje obiekty, które pracownik biznesowy wykorzystuje, produkuje, bada, kontroluje; ma charakter statyczny 47

48 Business Object Model - przykład Produkt Sprzedawca Kontroler Wyciąg z operacji Paragon Karta przewozowa 48

49 Katedra Informatyki Gospodarczej Szkoła Główna Handlowa Dziękuję za uwagę