Model biznesowy: co to za zwierze?

Model biznesowy: co to za zwierze? Coraz częściej spotykam się w literaturze z twierdzeniem, że poprawny projekt dotykający reorganizacji firmy, a więc w szczególności wdrażanie technologii IT, powinien zawierać analizę i opis środowisko biznesowego firmy. Najskuteczniej jest oprzeć się tu na modelu biznesowym. Pojęcie modelu biznesowego plącze się po sieci i literaturze. Praktycznie każda firma go ma ale mało, która wie o tym i potrafi go udokumentować. Ma taki model bo funkcjonuje na rynku ale ile firm ma te zasady udokumentowane w sposób spójny i zrozumiały dla pracowników i otoczenia? Osobna kwestią jest czy aktualny model jest dobry dla tej firmy bo okazuje się, że nie koniecznie. Nie raz okazuje się, że aktualny model prowadzi prostą drogą do bankructwa jednak o tym dowiadują się właściciele firm już po fakcie. Jak wykonać taki model i po co? W zasadzie nie ma jakiejś szczególnej metodologii jak to ma miejsce w przypadku modelowania procesów biznesowych (np. BPMN) czy systemu i jego otoczenia (np. UML). Jednak model to jednak model czyli uproszczony opis rzeczywistości ukierunkowany na zobrazowanie wybranych cech modelowanego przedmiotu. W przypadku modelu biznesowego jest to obraz metody budowania wartości na rynku. Powinien on moim zdaniem bazować na modelu łańcucha wartości (patrz E.Porter, Strategie Konkurencji). Metodyka modelowania BPMN na szczęście przewiduje także możliwość budowy modeli biznesowych (modelowania biznesu). Jak? Poza symbolami czynności i procesów udostępnia także symbole podmiotów oraz semantykę opisującą ich stosowanie. W efekcie otrzymujemy narzędzie, które pozwala modelować nie tylko procesy wewnątrz firmy ale także nadrzędny łańcuch zdarzeń czyli łańcuch wartości. Stąd już blisko do modelu biznesowego. Jeżeli podstawowy model łańcucha wartości wzbogacimy o możliwe inne relacje biznesowe to otrzymamy model mikrootoczenia rynkowego czyli jako całość będziemy dysponowali właśnie modelem biznesowym. Poprawnie wykonany model biznesowy opisuje i definiuje zarazem: źródła zaopatrzenia kanały zbytu wpływ konkurencji główne źródło marży (zysku) źródła zagrożeń Pozwala na zdefiniowanie Modelu Pięciu Sił Portera, który to model dodatkowo wzbogaca nasz model biznesowy o istotne informacje dotyczące obecnej i przyszłej konkurencyjności. Co z tego mamy? Ano mamy opis firmy i możliwość wskazania priorytetów w obszarach wymagań na system, tak ważnych przy określaniu wykonywalności projektu IT, w szczególności jego

rentowności. Mając model łańcucha wartości można łatwo zbudować model wewnętrznych procesów biznesowych, gdyż jest on ta na prawdę niczym innym jak dekompozycją modelu łańcucha wartości. Idąc wiec droga od opisu firmy do modelu jej procesów można zbudować np. taki oto model w notacji BPMN (od góry: model biznesowy, model procesów, wymagania na system IT) : Ale o tym w kolejnych artkułach po latach Mamy rok 2009, po kilku projektach analitycznych dotyczących właśnie analizy modeli biznesowych powstało poniższe opracowanie. Krótki opis Tekst ten adresowany jest do każdej osoby poszukującej wiedzy (metod) pozwalających na analizę zdarzeń gospodarczych, podmiotów gospodarczych i innych organizacji także tych nie mających charakteru komercyjnego. Celem tego opracowania jest przekazanie w skondensowanej, ale możliwie kompletnej formie, teoretycznej i praktycznej wiedzy z zakresu modelowania zjawisk rynkowych i podmiotów gospodarczych. Opracowanie stanowi monografię powstałą na bazie własnych badań i doświadczeń autora. Teorię, którą tu opisuję, należy raczej porównać do nauki geometrii której rozumienie pozwala narysować dowolną figurę geometryczną z pomocą cyrkla i linijki, nie jest to absolutnie próba tworzenia mało przydatnego do analizy, otworkowego wzornika figur geometrycznych. Pobierz opracowanie na temat analizy i tworzenia modeli biznesowych:

Przypadki użycia i UML: jak modelować Moim zdaniem błędem wielu projektantów programów (systemów) jest mniemanie, że projektują biznes. Nie! Projektują narzędzie biznesu a to jest istotna różnica. Krawiec nie modeluje i nie szyje człowieka tylko projektuje i szyje to, co człowiek na siebie założy, dlatego dobry garnitur musi mieć rozporek ale już nie koniecznie kieszeń na papier toaletowy. Jednak ten manekin musi być taki jak człowiek, model biznesu w oprogramowaniu także. Kiedy i po co modelują? Co to są te przypadki użycia? Najogólniej to lista czynności, które opisujemy tak by programista na ich podstawie wiedział jakie funkcjonalnosci ma realizować program. Moja praca nie raz dotyczy wykonania specyfikacji wymagań na system IT a to często są właśnie przypadki użycia. Praca moja na przypadkach użycia się kończy. Dalej już programiści a ja nim nie jestem. Ale do rzeczy. Opis przypadków użycia jest tak na prawdę zbiorem podstawowych wymagań funkcjonalnych i musi być jednoznaczny, spójny i kompletny. Jak ja sobie z tym radzę? Po wielu podejściach do tworzenia przypadków użycia uznałem, że należy najpierw opisać co jest w ogóle celem tworzenia tego systemu, co on ma wspomagać lub automatyzować. Jak? Należy najpierw zamodelować tę wspomaganą czynność w zupełnym oderwaniu od systemów. Jak już zdefiniujemy i zoptymalizujemy samą czynność można zabierać się do wyszczególniania przypadków użycia czyli tak na prawdę zaprojektować tę druga stronę lustra. Jak ja to robię? Tworzę model procesów (używam notacji i metodyki BPMN ale w prostszych przypadkach może to być np. diagram czynności UML), od którego proponuję zacząć. Potem wskazuję (wybieram) te czynności, które będą komputeryzowane (bo nie koniecznie wszystkie). W metodyce którą stosuję jest pojęcie czarnej skrzynki. Jest to np. projektowany jeszcze hipotetyczny system. Tworząc model procesów łączę czarną skrzynkę z wybranymi czynnościami (procesami) i optymalizuje tak powstały model. Prosty przykład poniżej:

Proszę zwrócić uwagę, że przerywane linie od modelu do czarnej skrzynki to kompletna lista przypadków użycia. Wystarczy je tylko zebrać i udokumentować np. tak jak w RUPie opisowo za pomocą tabel lub strukturalnego takstu. Podejście to wymaga troszkę więcej pracy ale ryzyko pominięcia czegoś istotnego jest minimalne dlatego warto ten czas poświęcić. Po drugie klient może łatwo taki model zweryfikować i zatwierdzić bo jest zrozumiały dla niefachowców. Kto choć raz zetknął z odbiorem systemu ten wie jak to ważne. 2012: obecnie stosuję metodę prostszą, oznaczanie czynności zakwalifikowanych jako przypadki użycia, zamiast budowania złożonego diagramu zawierającego pulę System. Więcej o przejściu z modelu procesu na przypadki użycia. Modelowanie biznesowe, czy to już dojrzała dyscyplina? Na razie widzę, że klarują się dwa podejścia: IDEF0 lub ICOM i pochodne (w tym EPC i eepc) inne idą w kierunku UML IDEF0 to kompletny model logiczny uwzględniający zasoby i cele biznesowe (które niestety często zatraca się w procesie modelowania!). UML to droga do zaprojektowania aplikacji. Myślę, że tą drogą w środku spotkają się analitycy i programiści. W miejscu gdzie mamy model procesowy i procedury (workflow) na najniższym poziomie dekompozycji programista obiektowy ma wszystkie informacje by z pomocą UML zaprojektować i napisać kod aplikacji. Każdy prosty bloczek modelu oraz interfejsy (formatki dokumentów) mogą teraz zostać zaimplementowane w systemie. Być może od strony modelowania BPMN (Business Process Modeling Notation) a od strony kodowania BPEL wniosą ułatwienie polegające na umożliwieniu pewnej automatyzacji tworzenia programów jednak w moim przekonaniu ważniejsze jest by precyzyjnie wskazać granice

kompetencji pomiędzy analitykiem a inżynierem i dokładnie na tej granicy umieścić styk narzędzi analitycznych i inżynierskich. Modelowanie to dziedzina prawie tak stara jak systemy informatyczne dla biznesu. Podstawowym celem modelowania procesów jest opisanie firmy, określenie celu projektu reorganizacyjnego i jego zakresu, określenie wymagań na tworzone oprogramowania a wcześniej optymalizacji organizacji i przygotowanie jej do wdrożenia. Stworzenie opisu funkcjonalnego tego co będziemy oprogramowywać zawsze było wyzwaniem trudnym. Drugim, być może jeszcze trudniejszym jest (do dzisiaj) nawiązanie nici porozumienia i zrozumienia pomiędzy sferą biznesu a inżynierami i programistami. Jedna z ról jaką ma do odegrania wykonany przez analityków model jest stworzenie szkieletu aplikacji lub przynajmniej opisu tego szkieletu. Naturalnym dążeniem jest także próba uniknięcia ręcznego przepisywania pracy analityków biznesowych modelu i wygenerowanie na jego podstawie kodu aplikacji lub przynajmniej jej modelu np. w postaci UML. Notacje i metodyki modelowania można podzielić na dwie grupy: 1. 2. modelowanie do prowadzenia analiz i optymalizacji procesów i zdarzeń gospodarczych (procesów biznesowych) modelowanie do celów tworzenia oprogramowania Na świecie nadal najpopularniejsze są: IDEF wśród analityków i UML wśród programistów. Modele analityczne Tu się niewiele zmieniło. Nadal w użyciu jest IDEF0 i jego odmiany a raczej warianty czyli ICOM i mniej znany IGOE. Skrót ICOM to: Input, Controll, Output, Mechanizm czyli Wejście, Sterowanie, Wyjście, Mechanizm (tu chodzi o zasoby). Skrót IGOE ma rozwiniecie: Input, Guide (odpowiednik sterowania), Output, Enabler (tu chodzi o zasoby w kontekście inicjatora realizacji danej funkcji). W obu przypadkach ogólny schemat procesu w tych konwencjach przedstawiany jest za pomocą prostokąta symbolizującego funkcję realizowaną przez proces oraz strzałki obrazujące wymienione cztery jego atrybuty : Na tym poziomie powstało wiele produktów, które niestety zawierają swoje unikalne rozszerzenia symboli i reguł. Doprowadziło to powstania wielu narzędzi do modelowania, których produkty są ze sobą niekompatybilne już na poziomie użytych symboli. Nie wymieniając ich tu napisze, tylko, że w dość powszechnym użyciu jest ich prawie dziesięć a Gartner zidentyfikował ich na rynku trzydzieści sześć. Z tego też powodu używam w pracy symboli ICOM prostych i zrozumiałych dla biznesu zaś w przypadkach bardziej sformalizowanych używam IDEF0. Z uwagi na stały rozwój także tych metod ostanio zainteresowąłem się notacją BPMN. Modelowanie do celów tworzenia oprogramowania Ten temat jest dużo trudniejszy, gdyż dążenie do realizacji sprzęgu pomiędzy analitykiem a informatykiem to temat istniejący od początku czasów tworzenia oprogramowania do celów biznesowych. Krótka historia narzędzi do modelowania na

potrzeby tworzenia oprogramowania (rok powstania i nazwa metody): 1962: sieci Petriego (Carl Petri Network) 1970: ANSI Flow charts 1979: DFD (Data Flow Diagram) 1982: ISO TC87 (ISO Conceptual Schema Model) 1992: Merise (Methode d Etude et de Realisation Informatique pour les Systemes d Enterprice) 1992; EPC (Eventdriven Process Chains) 1995: IDEF3 (Integrated Definition Method 3, Process Description Capture Method) 2001: ebxml v.1.1 (electronic business using extesible Markup Language) 2002: BPML v.1.1 (Busines Process Modeling Language) 2002: WSCi v.1.0 2003: BPEL4WS (Business Process Execution Language for Web Services) 2004: BPMN (Business Process Modeling Notation) (na podstawie Process modeling A Maturing Discipline?, Michael Rosemann, Maria Indulska, Peter Green, Quinsland University of technology Information). Sieci Petriego są nadal uważane za jedno z najskuteczniejszych narzędzi do modelowania jednak ich głównym ograniczeniem jest dość skomplikowany model matematyczny oraz brak hierarchizacji funkcji jak to ma miejsce w realnych organizacjach. Nie zawiera też w sobie narzędzi do opisu architektury obiektowej oprogramowania. Metody tworzenia oprogramowania zorientowane obiektowo doprowadziły do powstania narzędzi typu UML jednak są one bardzo trudne do zastosowania w modelowaniu biznesowym gdyż natura organizacji jest hierarchiczna a nie obiektowa. Modele obiektowe są po pierwsze praktycznie niezrozumiałe dla biznesu po drugie nie sprawdzają się jako narzędzie do opisu organizacji, która żyje i ewoluuje. Stale rozwijające się metody zarządzania ewoluują w stronę procesów biznesowych ich natura zaś jest jest hierarchiczna. Kolejną próbą rozwiązania problemu jest powstanie BPMN. BPMN Business Process Modeling Notation Ideą twórców BPMN jest stworzenie narzędzia dla analityków ale takiego, którego produkty da się tłumaczyć na BPEL4WS. Bazą dla BPMN są sieci Petriego i EPC. Dla tego z jednej strony kompletna lista symboli BPMN to 38 symboli obrazujących typowe zdarzenia biznesowe dające się odwzorować za pomocą BPEL4WS, modelować zaś można już za pomocą sześciu podstawowych, które pozwalają na zbudowanie pełnego modelu procesów biznesowych. Pozostałe symbole służą do dodatkowego definiowania zdarzeń koniecznych z punktu widzenia inżynierii oprogramowania. Dlatego np. model wykonany za pomocą podstawowego zestawu symboli przez analityka da się łatwo uzupełnić jako kontynuacja projektu o brakujące elementy w celu wygenerowania kodu dla BPEL. ten zaś być może będzie standardem służących do generowania kodu aplikacji jak dawne systemu typu CASE.

Notatka: W tym roku (2005) opublikowano wersję 1.0 notacji BPMN (Business Process Modeling Notation). 12 Września 2005 w Atlancie odbyła się konferencja BPMN Foundation na której między innymi ogłoszono połączenie Notation Working Group z OMG i specyfikację BPMN v.1.0. W planie jest RFC.