Katarzyna K.

Katarzyna K. Lider przyszłości :)

Witajcie :-)

Stanęłam właśnie przed wyborem "co wolę"... ;)

Do tej pory pisana była przeze mnie głównie analiza systemowa...
Tu UML wystarczał mi w 100% :)

Teraz stanęłam przed dalszym rozwojem, tj. pisania analizy biznesowej i teraz, zastanawiam się czy stosować dalej UML czy pójść tą "lżejszą" ścieżką i pisać w BPMN ?

A Wy ? co byście wybrali ? Co do was bardziej przemawia? może jakieś argumenty?

Co tak naprawdę bardziej pasuje do analizy biznesowej ?
Mateusz Kurleto

Mateusz Kurleto Szukamy wybitnych
talentów do
świetnego zespołu IT
w Gdańsku

Czy to jest alternatywa rozłączna?
Jednym z celów modelowania i analizy jest przedstawienie tego samego problemu z różnych punktów widzenia. Osobiście uważam, że BPMN jest lepszym narzędziem do modelowania procesów ponieważ:
- jest bardziej intuicyjny, łatwiejszy do zrozumienia dla odbiorcy biznesowego, który nie zna notacji
- lepiej przedstawia model procesów - bo do tego został stworzony - a ten z kolei jest, moim zdaniem, koniecznym elementem analizy biznesowej
- łatwiej z jego wykorzystaniem przedstawić wartość dodaną poszczególnych zadań w procesie
a dalej, jeśli analiza biznesowa przeprowadzona jest w celu zaproponowania rozwiązania technologicznego, szczególnie zaś IT, nie znam lepszego języka opisu wymagań funkcjonalnych oraz modelu dziedziny niż UML
Dlatego moim zdaniem odpowiedzią jest BPMN i UML - każdy w aspekcie do którego został stworzony.
Pewnie Jarek napisze więcej, jak go znam:)

konto usunięte

Moim zdaniem powinnaś poznać jedno i drugie, a przed pytaniem "co wykorzystać w danym przypadku" postawiłbym sobie pytanie "co lepiej rozumie mój klient i ludzie, z którymi pracuję".
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Bpmn ma semantyke stworzona dla modeli biznasowych i jest (do czytania) bardzo intuicyjny. Uml i jego obiektowy paradygmat (totalnie obcy biznesowi) jest doskonaly do modelowania konceocji wytworzenia oprogramowania. Jest w uml diagram czynnosci ale powstal raczej do modelowania algorytmow co sie ciagnie za nim . Nowy uml zostal rozwiniety i formalnie pozwala modelowac procesy ale w molm odczuciu to troszke jak mycie zebow lyzeczka - tez wklada sie ja do ust ale podobienstwo jednak zbyt male

konto usunięte

Katarzyna Kowalska:
Teraz stanęłam przed dalszym rozwojem, tj. pisania analizy biznesowej i teraz, zastanawiam się czy stosować dalej UML czy pójść tą "lżejszą" ścieżką i pisać w BPMN ?

Procesy BPNM, architektura UML. Nic nie stoi na przeszkodzie żeby znać i to i to. I bardzo bym uważał, ze stwierdzeniem, że analiza biznesowa jest "lżejsza" :).

Acha i jeszcze trzeba pamiętać, że notacja to przy analizie biznesowej rzecz wtórna i dotycząca głównie analizy procesów, czyli podzbioru analizy biznesowej. Analityk biznesowy nie tylko diagramy maluje ;)Dariusz G. edytował(a) ten post dnia 18.02.11 o godzinie 18:34
Katarzyna K.

Katarzyna K. Lider przyszłości :)

Dziekuje wam bardzo za informacje:)

Oczywiscie wiem, ze model biznesowy to nie tylko "diagramy" ale wiem tez ze czasami taki diagram potrafi zastapic całą kartę A4 tresci arial 8 ;-)

Jarku - lyzeczka rozbawila mnie najbardziej :-)
I oczywiscie tez jestem tego samego zdania, BPMN dla biznesu i tego sie bede trzymac ;)

Chcialam tylko potwierdzenia, jakby ktos zapytal "a dlaczego akurat to" ;)

poza tym, chce sie rozwijac i to bedzie kolejny krok w tym temacie:)

konto usunięte

Z tą intuicyjnością BPMNa to bym uważał. Podstawy to może są i intuicyjne, ale jak np. Gateway XOR wytłumaczyć biznesowi to już jest trudniej ;)
Trzeba uważać, żeby nie odlecieć jednak.
Co do diagramów czynności. Da się w tym modelować procesy i jak klient to rozumie, a BPMNa widzi pierwszy raz na oczy, to bym chyba jednak przełknął diagram czynności i nie robił rewolucji.
Jacek Sałacki

Jacek Sałacki analityk
biznesowy/project
manager

W pełni się podpisuję pod tym co o sprawie UML "kontra" BPMN napisali panowie powyżej.
Dodam tylko dwie uwagi:
Katarzyna Kowalska:
Teraz stanęłam przed dalszym rozwojem, tj. pisania analizy biznesowej i teraz, zastanawiam się czy stosować dalej UML czy pójść tą "lżejszą" ścieżką i pisać w BPMN ?

Z tą lekkością BPMNa bym był ostrożny. Ta notacja to około 100 różnych elementów, z które wszystkie mają swoje znaczenie. Opanowanie BPMNa i zrobienie poprawnego gramatycznie i znaczeniowo diagramu to nie jest banał. Łatwo można osiągnąć diagramy, które będą "brzmiały" tak:
http://www.youtube.com/watch?v=EORTlRvUAxg
:)
Katarzyna Kowalska:
Oczywiscie wiem, ze model biznesowy to nie tylko "diagramy" ale wiem tez ze czasami taki diagram potrafi zastapic całą kartę A4 tresci arial 8 ;-)

Z tym też byłbym ostrożny. Diagram i opis tekstowy raczej się uzupełniają a nie zastępują. Diagram bez sensownego opisu może być mało zrozumiały.Jacek Sałacki edytował(a) ten post dnia 18.02.11 o godzinie 21:45
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Xor to proste biznesowe "albo rybki albo akwarium" ja w obecnosci "biznesu" nie odważył bym sie użyć slowa xor :-) po drugie rombik z warunkiem tak/nie nie wymaga komentarza ;-)
Diagram czynnosci ma klopoty ze zdarzeniami a po drugie jest "niemiły dla oka" (slowa klienta)

konto usunięte

Jacek Sałacki:
Z tą lekkością BPMNa bym był ostrożny. Ta notacja to około 100 różnych elementów, z które wszystkie mają swoje znaczenie. Opanowanie BPMNa i zrobienie poprawnego gramatycznie i znaczeniowo diagramu to nie jest banał.

To, że jest 100 elementów, to jeszcze nie znaczy, że trzeba wszystkich używać, czy nawet znać i pamiętać. Im prościej tym lepiej, a przede wszystkim bardziej zrozumiale dla odbiorcy. Jakieś 90-95% typowych procesów da się opisać +/- używając maks. 15-20 elementów. Obciążanie sobie pamięci kompletną notacją jest nieco bezsensowne. Jak potrzeba, zawsze można zerknąć do źródeł. Chodzi o poznanie zasad i posiadanie ogólnego obrazu stosowania, a nie kucie do egzaminu ;). Mnie natomiast chodziło o to, że analizy biznesowe jako takie wcale nie należą do "lekkich" i bardzo łatwo można je spaprać. Tak naprawdę opisywanie poznanych procesów jest chyba najłatwiejszym z elementów. Cała zabawa za to jest z optymalizacją i KPI.Dariusz G. edytował(a) ten post dnia 19.02.11 o godzinie 05:00
Katarzyna K.

Katarzyna K. Lider przyszłości :)

No tak...

Tylko że w niektórych przypadkach (nie wiem jak jest u was) ale zdarza się że analizę biznesową robimy dla gotowego wytworzonego produktu, czyli kolejność nie taka;)

Dopiero teraz staram się wypracować "proces" który wszystkim podpasuje:)
Mając analizę biznesową to tylko krok do systemowej ;) I właśnie..

W większości firm, jest wręcz wymagane że to analityk (nie ważne czy systemowy czy inny) ma robić powyższą dokumentację...

A ostatnio na jednym ze szkoleń usłyszałam, że wcale nie - że takowy opis powinien utworzyć biznes czyli np.; osoba odpowiadająca za sprzedaz produktu...

Co o tym sadzicie? kto powinien utworzyc dokumentacje biznesową ?

I jeszcze jedno - szczerze mowiac analiza biznesowa to tak naprawde specyfikacja wymagan klienta (tak sądze) i stad dopiero po spisaniu wymagan dot. produktu, powstaja dalsze dokumentacje - takze szczegolowych notacji BPMN naprawde nie trzeba sie uczyc;) Wazne by byly podstawy, a jak kolega napisal - zawsze mozna siegnac do zrodel ;) Ja osobiscie spotkalam sie juz z opinia pokazujac i BPMN i UML, ze jednak BPMN jest "łatwiejszy" w "czytaniu"

A co do diagramow i opisow - oczywiscie ze nie sa zastepowalne, ale uwierz mi ze dobrym prostym diagramem unikasz wielokrotnie zlozonych zdan ;)

konto usunięte

Katarzyna Kowalska:
No tak...

Tylko że w niektórych przypadkach (nie wiem jak jest u was) ale zdarza się że analizę biznesową robimy dla gotowego wytworzonego produktu, czyli kolejność nie taka;)
Dopiero teraz staram się wypracować "proces" który wszystkim podpasuje:)

Wszystkim to nigdy nie podpasujesz :). A od takiego podejścia to trochę się włos jeży. Ale owszem, częste niestety.
Mając analizę biznesową to tylko krok do systemowej ;) I właśnie..
W większości firm, jest wręcz wymagane że to analityk (nie ważne czy systemowy czy inny) ma robić powyższą dokumentację...

A ostatnio na jednym ze szkoleń usłyszałam, że wcale nie - że takowy opis powinien utworzyć biznes czyli np.; osoba odpowiadająca za sprzedaz produktu...

Co o tym sadzicie? kto powinien utworzyc dokumentacje biznesową ?

Wszystko zależy od skali, branży, skomplikowania. Nie ma zasad. Są Programiści-Analitycy-Kierownicy Projektów z funkcją Sprzedażową. Są dedykowane osoby do poszczególnych zadań/obszarów i tylko tym się zajmują. Poza tym trzeba by zdefiniować co to znaczy "dokumentacja biznesowa" - określenie na tyle szerokie, że można tu wszystko wrzucić, nawet sny prezesa o potędze.

I jeszcze jedno - szczerze mowiac analiza biznesowa to tak naprawde specyfikacja wymagan klienta (tak sądze) i stad dopiero

Absolutnie nie. Specyfikacja to specyfikacja, analiza to analiza. Specyfikacja odpowiada na pytanie CO?, analiza JAK? KIEDY? GDZIE? Specyfikacja może natomiast być wynikiem analizy.
A co do diagramow i opisow - oczywiscie ze nie sa zastepowalne, ale uwierz mi ze dobrym prostym diagramem unikasz wielokrotnie zlozonych zdan ;)

Nie od dziś wiadomo, że obraz dociera lepiej niż tekst ;). Choć nie w każdym przypadku. Notacje wszelkiego typu powstały głównie po to żeby pewne rzeczy standaryzować (żeby były przenaszalne, odzwierciedlalne, porównywalne, etc.), funkcja "docierania" jest wtórna.Dariusz G. edytował(a) ten post dnia 19.02.11 o godzinie 17:55

konto usunięte

Katarzyna Kowalska:
I jeszcze jedno - szczerze mowiac analiza biznesowa to tak naprawdę specyfikacja wymagań klienta (tak sądzę) i stad dopiero po spisaniu wymagań dot. produktu, powstają dalsze dokumentacje - także szczegółowych notacji BPMN naprawdę nie trzeba się uczyć;)

No właśnie odwieczny problem, gdzie kończy się biznes, a zaczyna informatyka.
Ostatnio zmierzyłem się z tematem przy okazji pisania artykułu do SDJ o analityku systemowym.
Doszedłem do wniosku, że najbardziej wyrazistą różnicą między analizą biznesową, a systemową jest to, że analiza systemowa jest robiona na potrzeby systemu informatycznego, a biznesowa w ogóle nie musi z systemem informatycznym mieć nic wspólnego. Analizę biznesową można robić np. po to, aby zoptymalizować proces biznesowy w ogóle nie dotykający żadnego systemu.
Co do ściąg, gorąco polecam http://www.itposter.net/ kopalnia ciekawych ściąg. Między innymi BPMN i UMl, wzorce projektowe i wiele innych. Bardzo przydatna rzecz.Grzegorz Kukawski edytował(a) ten post dnia 19.02.11 o godzinie 21:29
Katarzyna K.

Katarzyna K. Lider przyszłości :)

Grzegorzu: Dziekuje bardzo za linka - faktycznie ogrom przydatnej wiedzy :)

I mi właśnie o to chodzi, że biznes nie musi mieć nic wspólnego z analizą systemową, stąd (Darku) nawiązałam do "specyfikacji" choć tak naprawdę to chodziło mi o prosty opis tego co klient chce:) Specyfikacja to w tym przypadku jednak zbyt mocne słowo;)

Tak naprawdę idąc ścieżką od początku - biznes określa produkt - czyli co chcą sprzedawać - następnie "specyfikuje" - opisuje to czego oczekuje od tego produktu (tu wkracza model biznesowy) a następnie jest to przekazywane do analityka który opisuje to systemowo, czyż nie tak to powinno wyglądać?

Bo może ja mam mylne wyobrażenie, naprowadźcie mnie zatem, jeśli jest inaczej :-)

Oczywiście praktyka mówi mi co innego niż to co opisałam powyżej ;)
Michał P.

Michał P. Integrator systemów

chciałbym wtrącić swoje dwa grosze..
moim zdaniem czasami BPMN i UML można traktować jako alternatywę: zależy co przyjmiemy jako "cegiełkę" z której będziemy budować system - jeżeli myślimy o obiektach (klasach) wtedy naturalnym jest UML, natomiast gdy budujemy system na podstawie procesów biznesowych jako podstawowych cegiełek, wybierzemy BPMN.
Często niestety niedojrzałość firmy klienta nie pozwoli nam na zdefiniowanie wyizolowanych procesów biznesowych i o BPMN możemy niestety zapomnieć.

konto usunięte

Dariusz G.:
Tak naprawdę opisywanie poznanych procesów jest chyba najłatwiejszym z elementów. Cała zabawa za to jest z optymalizacją i KPI.Dariusz G. edytował(a) ten post dnia 19.02.11 o godzinie 05:00
Mnie się wydaje, że to raczej odwrotnie.
Opisywanie procesów w ten sposób, by "wymyśleć" sensowne i interesujące dla nas mierniki, a to wszak wchodzi w zakres opisu procesu, to jest dopiero wyzwanie. A jak już mamy odpowiednie parametry i procesu i ewentualnie poszczególnych zadań, czy czynności, to optymalizacja procesu (czyli przejście z AS-IS do TO-BE) to sama przyjemność. Wystarczy wszak tylko zaimplementować odpowiednie algorytmy i "bawimy" się parametrami patrząc jakie mierniki, według nas, są najlepsze. Przy tej "zabawie" to już można nawet "wyłączyć myslenie" i pilnować jedynie, w trakcie symulacji, jakie parametry nam rosną, a jakie opadają ;)

konto usunięte

Stanisław Niepostyn:
Mnie się wydaje, że to raczej odwrotnie.
Opisywanie procesów w ten sposób, by "wymyśleć" sensowne i interesujące dla nas mierniki, a to wszak wchodzi w zakres opisu procesu, to jest dopiero wyzwanie. A jak już mamy odpowiednie parametry i procesu i ewentualnie poszczególnych zadań, czy czynności, to optymalizacja procesu (czyli przejście z AS-IS do TO-BE) to sama przyjemność. Wystarczy wszak tylko zaimplementować odpowiednie algorytmy i "bawimy" się parametrami patrząc jakie mierniki, według nas, są najlepsze. Przy tej "zabawie" to już można nawet "wyłączyć myslenie" i pilnować jedynie, w trakcie symulacji, jakie parametry nam rosną, a jakie opadają ;)

No tak nie do końca. Nie zawsze opis procesu jest tożsamy z jego optymalizacją i nie zawsze się ustala KPI. Szczególnie w przypadku procesów dobrze znanych i typowych, które się dokumentuje dla potrzeb innych niż optymalizacja. Symulować sobie oczywiście można do woli. Aczkolwiek trzeba mieć na to budżet i czas ;). Poza tym symulacja, to tylko symulacja. Trzeba mieć ograniczone zaufanie. Rozmowy z właścicielem procesu nic nie zastąpi.

konto usunięte

Dariusz G.:
Stanisław Niepostyn:
Mnie się wydaje, że to raczej odwrotnie.
Opisywanie procesów w ten sposób, by "wymyśleć" sensowne i interesujące dla nas mierniki, a to wszak wchodzi w zakres opisu procesu, to jest dopiero wyzwanie. A jak już mamy odpowiednie parametry i procesu i ewentualnie poszczególnych zadań, czy czynności, to optymalizacja procesu (czyli przejście z AS-IS do TO-BE) to sama przyjemność. Wystarczy wszak tylko zaimplementować odpowiednie algorytmy i "bawimy" się parametrami patrząc jakie mierniki, według nas, są najlepsze. Przy tej "zabawie" to już można nawet "wyłączyć myslenie" i pilnować jedynie, w trakcie symulacji, jakie parametry nam rosną, a jakie opadają ;)

No tak nie do końca. Nie zawsze opis procesu jest tożsamy z jego optymalizacją
Czy gdzieś tak napisałem ?
Rozmowy z właścicielem procesu nic nie zastąpi.
A rozmowa z właścicielem procesu to opis procesu, czy optymalizacja procesu ?
Aleksander Płaczek

Aleksander Płaczek Software Development
Manager, Delivery
Manager

Grzegorz Kukawski:
Katarzyna Kowalska:
I jeszcze jedno - szczerze mowiac analiza biznesowa to tak naprawdę specyfikacja wymagań klienta (tak sądzę) i stad dopiero po spisaniu wymagań dot. produktu, powstają dalsze dokumentacje - także szczegółowych notacji BPMN naprawdę nie trzeba się uczyć;)

No właśnie odwieczny problem, gdzie kończy się biznes, a zaczyna informatyka.
Ostatnio zmierzyłem się z tematem przy okazji pisania artykułu do SDJ o analityku systemowym.

A jak bym podszedł do temat poruszonego przez Kaśkę z trochę innej strony. W swoim artykule Grzegorz również o tym wspomina, choć niejawnie. Tak naprawdę nie ma znaczenia notacja, którą wybierzemy do modelowania biznesu, gdyż zawsze możemy trafić na klienta, który albo:
a) będzie kojarzył notację BPMN i dobrze to zrozumie, ale kompletnie nie będzie rozumiał nawet prostych diagramów UML
b) będzie kojarzył i rozumiał diagramy UML, lecz podejście procesowe będzie mu obce
Dlatego niewykluczone, że będziemy musieli dobierać notację do sytuacji (klienta). Czasami wystarczy tzw. "opis muzyczno - słowny". Pytanie bardziej należy postawić: jaka jest rola analityka biznesowego i czy słownik wyniesiony z analizy systemowej jest wystarczający do nowej roli ? Moim zdaniem nie, bo analiza biznesowa to próba porozmawiania z klientem o jego pracy w jego języku. Dlatego zamiast uczyć się narzędzi, bardziej zainteresowałbym się dziedziną, w której Kaśka zamierza być analitykiem biznesowym. Owszem sposób pracy wyniesiony z analizy systemowej bardzo pomaga w zorganizowaniu sobie pracy, ale ... sporo pracy należy raczej włożyć w dobre poznanie dziedziny, w której chcemy modelować biznes.

Nie bez powodu, wiele firm poszukuje analityków biznesowych z doświadczeniem z konkretnej dziedziny (umiejętność posługiwania się odpowiednim słownikiem), który będzie nie tylko opisywał rzeczywistość, ale również starał się ją "lekko" (podkreślam lekko) optymalizować pod kątem możliwości jakie daje dzisiaj technologia. A do tego trzeba rozumieć klienta i procesy danej branży.
I dlatego uważam, że najlepszymi analitykami biznesowymi dla firm IT są ludzie, którzy pracowali "po stronie klienckiej" przez wiele lat. Ich dużo łatwiej nauczyć notacji, diagramów, narzędzi CASE niż informatyka myślenia pro-biznesowo.

Idealny duet = analityk biznesowy + analityk systemowy (osobne role). A pełny szał to wtedy, gdy jeszcze klient wie czego potrzebuje i co chce osiągnąć (co, a nie jak).
Katarzyna K.

Katarzyna K. Lider przyszłości :)

Aleksander Płaczek:

Idealny duet = analityk biznesowy + analityk systemowy (osobne role). A pełny szał to wtedy, gdy jeszcze klient wie czego potrzebuje i co chce osiągnąć (co, a nie jak).

-> Takie rzeczy... tylko w erze;)
Oczywiście że jest to idealny duet - ale bardzoooo rzadko spotykany;)

Niestety w większości jest tak, że wymaga się od analityków - szału:)

I niestety x2 - biznes nigdy nie będzie posługiwał się tym samym słownikiem co "analityk systemowy" - baaardzo ciężko to pogodzić - ale nie mówię że jest to niewykonalne;)

Pracowałam dość długo z klientem, także jest mi łatwiej ale to wcale nie oznacza, że muszę pisać analizę biznesową ;) Ale niestety, jak to w życiu bywa... ;)

Pozdrawiam wszystkich :-)

Wyślij zaproszenie do