Michał P.:
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ć.

Kompletna bzdura. To dwie różne notacje służące opisywaniu tego samego modelu z różnych perspektyw.
Jak chcesz pisać system skoro nie umiesz modelować wymagań? Jeśli ktoś ma nie dojrzałą firmę, to musi najpierw dojrzeć. Inaczej naciągasz klienta na robienie systemów, które nic mu nie dają.

Dariusz G.:

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.

To że wspomniałem o 100 elementach nie znaczy, że mówię o ich uczeniu się na pamięć. Mówię "tylko" o zrozumieniu znaczenia tych elementów.
Co z tego, że przeważnie używa się 15-20 elementów, jeżeli:
a) musisz wybrać których używasz a których nie (czyli rozumieć do czego służą)
b) musisz wiedzieć jak je wzajemnie powiązać
c) musisz rozumieć jak znaczek w BPMN przekłada się na modelowaną rzeczywistość (czyli co oznacza)

BPMN (i UML) jest po prostu językiem, którym trzeba się posługiwać w określony sposób - czyli używając właściwej gramatyki i semantyki. Brak umiejętności poprawnego składania zdań (modeli) w BPMN może spowodować tylko i wyłącznie chaos informacyjny. Bo strona która miała być odbiorcą takiego modelu albo go nie zrozumie, albo zrozumie całkiem coś innego niż chciałeś przekazać.
A gramatyki i semantyki BPMN, wbrew pozorom, nie ma prostej.

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:)
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ą ?

Jeżeli masz na myśli dokumentację wymagań lub dokumentację po projektową (opisującą działanie systemu z pkt. widzenia użytkownika lub właściciela) to powinien to moim zdaniem robić analityk. I nie tylko dlatego że za taką robotę mi płacą :)
Z moich doświadczeń wynika, że do stworzenia ww. opisu, zwłaszcza wymagań, konieczne jest umiejętność spojrzenia na problem we właściwy sposób - rozłożenia go na części, znalezienie zależności, jednocześnie pamiętając o wszystkich istotnych szczegółach ale bez zajmowania się nieistotnymi.

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 ;)

Wszystko zależy od tego w jakiej branży, jakie procesy, na jakim poziomie, dla kogo (kto ma je przeczytać) opisujesz.

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

Zdania wielokrotnie złożonego raczej nie zastąpisz prostym diagramem :) Bardziej chciałem zwrócić uwagę, że diagramy i tekst opisują to samo (system, biznes) tylko robią to na różnych poziomach, w różny sposób, skupiając się na różnych detalach. Dlatego się raczej uzupełniają a nie zastępują.

Mateusz Kurleto:

Michał P.:
Często niestety niedojrzałość firmy klienta nie pozwoli nam na zdefiniowanie wyizolowanych procesów biznesowych i o BPMN możemy niestety zapomnieć.

Kompletna bzdura. To dwie różne notacje służące opisywaniu tego samego modelu z różnych perspektyw.
Jak chcesz pisać system skoro nie umiesz modelować wymagań? Jeśli ktoś ma nie dojrzałą firmę, to musi najpierw dojrzeć. Inaczej naciągasz klienta na robienie systemów, które nic mu nie dają.

Spokojnie, nie tak ostro.
Organizacja może być "dojrzała", aby robić swój biznes, a nie żeby rozumieć jakieś notacje.
Twoim zadaniem jest, jako analityka, aby pomóc klientowi pomimo tego, że on nie rozumie BPMN, czy czegokolwiek innego. Jak ma firmę i zarabia, to znaczy, że wie co robi, co nie znaczy że nie ma się czego uczyć.
To raczej z nas żadni analitycy jak nam brak wiedzy klienta w czymkolwiek przeszkadza w tym, aby mu pomóc.

Grzegorz Kukawski:

Mateusz Kurleto:

Michał P.:
Często niestety niedojrzałość firmy klienta nie pozwoli nam na zdefiniowanie wyizolowanych procesów biznesowych i o BPMN możemy niestety zapomnieć.

Kompletna bzdura. To dwie różne notacje służące opisywaniu tego samego modelu z różnych perspektyw.
Jak chcesz pisać system skoro nie umiesz modelować wymagań? Jeśli ktoś ma nie dojrzałą firmę, to musi najpierw dojrzeć. Inaczej naciągasz klienta na robienie systemów, które nic mu nie dają.

Spokojnie, nie tak ostro.

A bo za bardzo uciałem Michała posta. Bzdura miała się odnosić do: "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"

Organizacja może być "dojrzała", aby robić swój biznes, a nie żeby rozumieć jakieś notacje.

Mi nie chodzi o rozumienie jakiejkolwiek notacji. Chodzi o działanie w sposób umożliwiający opisanie modelu biznesowego procesami.
Michał pisał, że jeśli organizacja nie jest dość dojrzała to należy zapomnieć o BPMN. Ja twierdzę, że jeśli w firmie nie istnieją procesy to należy zapomnieć o wdrożeniu, chyba, że jest gotowa ukryte w codziennej działalności procesy wydobywać, dopracowywać, formalizować i wdrażać.
Inaczej na pewno każde pieniądze na IT będą wyrzucone w błoto, bo Office do wszystkiego wystarczy.

Twoim zadaniem jest, jako analityka, aby pomóc klientowi pomimo tego, że on nie rozumie BPMN, czy czegokolwiek innego. Jak ma firmę i zarabia, to znaczy, że wie co robi, co nie znaczy że nie ma się czego uczyć.

Tu się nie zgodzę - że znaczy to że wie co robi. Wiele biznesów MŚP jst niepowtarzalnych i jest dziełem przypadku.

To raczej z nas żadni analitycy jak nam brak wiedzy klienta w czymkolwiek przeszkadza w tym, aby mu pomóc.

Tu się zgadzam - znaczy niewiedza może mi przeszkadzać, ale winienem umieć sobie z nią radzić.Mateusz Kurleto edytował(a) ten post dnia 21.02.11 o godzinie 00:18

My tu baju baju, a podstawowe zadanie analityka (systemowego), to przekładanie języka biznesu na język IT i odwrotnie. Jak tego nie potrafi sprawnie robić to żadna notacja mu nie pomoże.

Analityka biznesowego bym tutaj w ogóle nie mieszał, bo jego spektrum zadań i analiz wykracza zazwyczaj poza czyste IT.

Oczywiście w modelowej sytuacji są to rozłączne role. Niestety od modelu nader często są odstępstwa.

@Jacek

Każde narzędzie trzeba umieć używać. Czy jest to BPMN, czy zwykły młotek. Z tym nie dyskutuję.

@Aleksander

100% racji. Bez poznania danego obszaru biznesowego ciężko być analitykiem biznesowym. Nie bez przyczyny są ludzie specjalizujący się w finansach, logistyce, magazynowaniu, zarządzaniu jakością, etc. itd.

Stanisław Niepostyn:

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 ?

Skoro negujesz moje twierdzenie, że opis procesu może być prostszy niż jego optymalizacja, to tak właśnie napisałeś :).

Rozmowy z właścicielem procesu nic nie zastąpi.

A rozmowa z właścicielem procesu to opis procesu, czy optymalizacja procesu ?

A to zależy co mamy na celu. I podpowiem. Nie chodzi o symulację :)

Hint: Ustalmy może najpierw co to jest opis procesu dla kogo :) Czy tylko sam diagram przyczynowo-skutkowy wraz z identyfikacją właściciela(i) i przebiegu procesu oraz jego interakcjami? Czy od razu propozycja optymalizacji i KPI?

W zdecydowanej większości wdrożeń (jak już o IT mówimy) o optymalizację i KPI się nawet nie zahacza. Do odzwierciedlenia procesu w systemie wystarcza jego porządna identyfikacja i opis (w tym również modyfikacja - nie mylić z optymalizacją). A czemu się nie zahacza? A temu, że optymalizacja procesu i pomiar efektywności należy do właściciela tego procesu (lub jego przełożonego), m. in. dlatego że oni swoje procesy i specyfikę pracy najlepiej znają. Analityk może doradzić i zaproponować, ale nigdy nie powinien na siłę robić optymalizacji za kogoś. Istotna jest również kwestia kosztów analizy biznesowej. Firmy wcale nie są takie chętne żeby ponosić ekstra koszty w tym temacie.

Oczywiście zagadnienie jest dużo bardziej rozbudowane. Zależy po co jest robiona analiza. Czy jako przygotowanie do wdrożenia? Czy jako jego element? Czy wchodzimy do firmy gdzie jest tabula rasa? Czy tam gdzie coś źle działa, ale nikt nie wie co? Czy analiza jest robiona pod nowy produkt? A może reorganizację? A może ISO? A może po prostu ktoś wpadł na pomysł że warto się w czysty BPR pobawić? Wszystko zależy. Nie ma jednego "złotego środka".Dariusz G. edytował(a) ten post dnia 21.02.11 o godzinie 01:04

Dariusz G.:

No tak nie do końca. Nie zawsze opis procesu jest tożsamy z jego optymalizacją

Czy gdzieś tak napisałem ?

Skoro negujesz moje twierdzenie, że opis procesu może być prostszy niż jego optymalizacja, to tak właśnie napisałeś :).

A wydawało mi się, że napisałem, że opisywanie procesu jest trudniejsze, anizeli optymalizacja ;)
W takim razie bardzo przepraszam, że inaczej zinterpretowałeś moją wypowiedź, niezgodnie z moim zamiarem ;)

Rozmowy z właścicielem procesu nic nie zastąpi.

A rozmowa z właścicielem procesu to opis procesu, czy optymalizacja procesu ?

A to zależy co mamy na celu. I podpowiem. Nie chodzi o symulację :)

Hint: Ustalmy może najpierw co to jest opis procesu dla kogo :) Czy tylko sam diagram przyczynowo-skutkowy wraz z identyfikacją właściciela(i) i przebiegu procesu oraz jego interakcjami? Czy od razu propozycja optymalizacji i KPI?

W BPR: Modelowanie, Symulacja, Analiza, Optymalizacja.
Modelowanie:Opracowanie modelu AS-IS, specyfikacja parametrów biznesowych opisujących proces, specyfikacja algorytmów wyliczania parametrów
Symulacja: symulacja możliwych scenariuszy, symulacja przy różnych parametrach wejściowych
Analiza: Kalkulacja poszczególnych algorytmów, identyfikacja wąskich gardeł procesu lub nieproduktywnego wykorzystania zasobu
Optymalizacja: Opracowanie modelu TO-BE.

Przyjmijmy, że opis procesu to tylko modelowanie, a pozostałe etapy to optymalizacja.

W zdecydowanej większości wdrożeń (jak już o IT mówimy) o optymalizację i KPI się nawet nie zahacza. Do odzwierciedlenia

Wprost przeciwnie ;) W większości wdrożeń od razu przechodzi się do optymalizacji zupełnie nie zawracając sobie głowy aktualnym stanem. innymi słowy: wdrożamy tak jak w innych firmach (bo nam wygodnie), natomiast Klient sam musi się przystosować do naszej koncepcji wdrożenia. A jak chce wyliczyć jakieś współczynniki, czy parametry to jego sprawa. Nieprawdaż ?

Oczywiście zagadnienie jest dużo bardziej rozbudowane. Zależy po co jest robiona analiza. Czy jako przygotowanie do wdrożenia?

Jak Klient chce to mu jakąś tam analizę AS-IS na siłę zrobimy, ale my od razu przechodzimy do optymalizacji (czyli do modelu TO-BE), a więc przedstawiamy mu nasz "genaialny" plan wdrożenia i mówimy ile jeszcze musi wydać kasy, by móc ogłosic światu, że wdrożył nowoczesne technologie u siebie ;)

Dlatego też opis procesu wydaje się nam tak zdumiewająco prosty (po prostu zazwyczaj go nie robimy).
A to nie tak ;) Największy ból głowy, gdybyśmy uczciwie podeszli do optymalizacji procesów biznesowych, to znaczy najpierw wymyslili odpowiednie parametry procesu i sposób obliczania tych parametrów, nie mówiąc o samym modelu AS-IS (ale komu to potrzebne?).
Przykładowo jak opisać proces, a nawet same jego parametry, gdybyśmy chcieli zoptymalizować proces obsługi faktur kosztowych pod kątem zmniejszenia kosztów na etaty osób tam zatrudnionych ?
Weź dowolny system IT i zawsze Ci wyjdzie, że wdrożenie dowolnego systemu informatycznego, by zredukować personel jest bardzo nieopłacalne i nieekonomiczne !!! Czemu więc firmy informatyzują swoją księgowość ?

Czy jako jego element? Czy wchodzimy do firmy gdzie jest tabula rasa? Czy tam gdzie coś źle działa, ale nikt nie wie co? Czy analiza jest robiona pod nowy produkt? A może reorganizację? A może ISO? A może po prostu ktoś wpadł na pomysł że warto się w czysty BPR pobawić? Wszystko zależy. Nie ma jednego "złotego środka".Dariusz G. edytował(a) ten post dnia 21.02.11 o godzinie 01:04

Katarzyna Kowalska:
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...

to prosta droga do porażki...

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

analityk, podobnie jak dokumentację lekarską o mnie pisze lekarza a nie ja sam...

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

należy odróżnić analizę od "user story"....

Katarzyna Kowalska:
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;)

definicja słowa "system" to "zespół elementów współdziałających", nie jest to "coś informatycznego" (choć może być). Dlatego lepiej unikać słowa system mającego szerokie znaczenie a używać prostych pojęć:
- analiza biznesowa daje jako produkt model organizacji modelowanej (BPMN)
- analiza wymagań daje w efekcie listę potrzeb informacyjnych, do jej opracowania potrzebna jest własnie wiedza o organizacji i pełne jej zrozumienie - efekt analizy biznesowej (UML)
- oprogramowanie składa się między innymi z dwóch zasadniczych części: obiektów biznesowych i ich logiki biznesowej (to ktoś musi zaprojektować np. w UML ale na pewno nie w BPMN) oraz całej pozostałej części, tej pierwszej żaden projektant programista, systemowy analityk (co to jest??) nie stworzy, jak zacznie to tylko kłopoty.

gorąco polecam podział pracy pomiędzy wykonawce oprogramowania a projektanta tego do czego to oprogramowanie ma posłużyć. Murarz nie projektuje domów a architekt nie buduje.

Niestety praktyka jest taka, że większość firm dostarczających oprogramowanie uważa, że jest mądrzejsza od swoich klientów i to jest tragedia... tragedią jest także to, że niektórzy klienci "wiedza lepiej"...Jarek Żeliński edytował(a) ten post dnia 21.02.11 o godzinie 09:37

Michał P.:
Często niestety niedojrzałość firmy klienta nie pozwoli nam na zdefiniowanie wyizolowanych procesów biznesowych i o BPMN możemy niestety zapomnieć.

nie, należy wtedy zapomnieć w ogóle o projekcie jakiegokolwiek oprogramowania dla takiej firmy, trzeba czekać aż dojrzeje... do zamawiania oprogramowania albo do zlecenia komuś analizy i udokumentowania modelu biznesowego ....

Aleksander Płaczek:
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,

ma ogromne...

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

modele są narzędziem analizy a nie jej produktem... wiec klientowi tu nic do rzeczy, jak nie rozumie to musi zawierzyć analitykowi (dokładnie tak samo jak lekarzowi)

b) będzie kojarzył i rozumiał diagramy UML, lecz podejście procesowe będzie mu obce

jak wyżej...

Dlatego niewykluczone, że będziemy musieli dobierać notację do sytuacji (klienta).

a jaki poza, BPMN i UML mamy wybór? (mowa o notacjach dobrze sformalizowanych, inne to raczej obrazki a nie modele).

Czasami wystarczy tzw. "opis muzyczno - słowny".

super, poczekam rok, będę ja albo ktoś miał nowego klienta :), chyba że ktoś mi pokaże metodę "walidacji" opisu słowno-muzycznego...

bo analiza biznesowa to próba porozmawiania z klientem o jego pracy w jego języku.

zapisałem w pamiętniku tę definicję :)

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).

pełny szał to pacjent, który przychodzi do lekarza od razu z dobrze postawioną diagnozą... super (wybaczcie ironie, nie mogłem się powstrzymać).

Jacek Sałacki:

Dariusz G.:

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.

Oooooooooooo, a ja patrzę na specyfikację i widzę raptem siedem podstawowych plus opisy.... czy aby mowa o tym samym???
(dla ułatwienia: czynność, zdarzenie, sterowanie, komunikat, obiekt danych, bramka plus oznaczenia komentarzy)

Co z tego, że przeważnie używa się 15-20 elementów, jeżeli:
a) musisz wybrać których używasz a których nie (czyli rozumieć do czego służą)
b) musisz wiedzieć jak je wzajemnie powiązać
c) musisz rozumieć jak znaczek w BPMN przekłada się na modelowaną rzeczywistość (czyli co oznacza)

po pierwsze wyzwaniem jest (nie przeczę) analiza i tworzenie modeli ale ich czytanie to banał... po jednodniowym szkoleniu ...

BPMN (i UML) jest po prostu językiem, którym trzeba się posługiwać w określony sposób - czyli używając właściwej gramatyki i semantyki. Brak umiejętności poprawnego składania zdań (modeli) w BPMN może spowodować tylko i wyłącznie chaos informacyjny.

[...]

A gramatyki i semantyki BPMN, wbrew pozorom, nie ma prostej.

bo do czytania dobrych wierszy wystarczy umieć czytać, ich pisanie jest większym wyzwaniem, więc co innego analityk i modelowanie a co innego przyuczenie klienta do czytania diagramów.

poczytałem i na pytanie BPMN czy UML powiem tak:
- to dwie różne notacje i nie ma sensu pytanie "czy", ma sens pytanie kiedy której użyć
- co do podziału na takiego czy innego analityka dyskusja jest bez sensu dopóki nie powiemy sobie jaki i kto ma produkt dostarczyć.

tu przykład tego kiedy jakiej notacji można użyć:




Dostrzegam także pewne zgubny tok myślenia: notacja jest sposobem na problem: nie nie jest, mój stryj mawia: nie ma znaczenia to czy i jakie znasz języki obce, znaczenie ma to czy ma w nich coś do powiedzenia....

dalej: firmie programistycznej BPMN na grzyba, UML jak najbardziej, analityk biznesowy BPMN w zasadzie znać powinien, a UML praktycznie też, bo on musi jakoś swą wiedzę o potrzebach klienta przekazać programistom, jeśli robi to prozą to tragedia, programiści modeli BPMN nie zamienią na kod programu, a analityk kodu za nich nie napisze bo byłby programistą, pozostaje UML i zamodelwoanie tego co programiści maja napisać....

w efekcie mamy sprawna maszynę:
- analityk biznesowy opisze dokładnie (stworzy jej model) firmę klienta
- wraz z klientem określi zakres projektu i spisze wymagania (specyfikacja np. Use CAse i ograniczenia)
- zaprojektuje logikę tego co ma powstać (UML)
- developer wykona to co zaprojektowano (wybrana technologia...)

tak powstają programy w pierwszym podejściu a nie w "kolejnym prototypie"...Jarek Żeliński edytował(a) ten post dnia 21.02.11 o godzinie 11:30

Dostrzegam także pewne zgubny tok myślenia: notacja jest sposobem na problem: nie nie jest, mój stryj mawia: nie ma znaczenia to czy i jakie znasz języki obce, znaczenie ma to czy ma w nich coś do powiedzenia....

Wiedza, wiedza i jeszcze raz doświadczenie.

Jest taki żarcik o człowieku, który na poczcie w czterech językach próbuje się dowiedzieć czegoś od Pani w okienku. Ona oczywiście nic nie kuma, a gdy koleżanka zwraca jej uwagę, że gdyby znała języki to by się z nim dogadała pada jej odpowiedź: On znał a się nie dogadał.

Wybór notacji pozwoli nam na usystematyzowanie podejścia i zgromadzonej wiedzy. Pozwoli na uporządkowanie zależności między poszczególnymi elementami analizy (tak jak to zaznaczyłeś w przykładowym diagramie). Natomiast braki w odpowiedniej klasyfikacji obiektów świata rzeczywistego widoczne są potem na lukach w modelu dziedziny. A takie braki przenoszą się na niedoskonałości systemu, które mogą na wczesnej fazie analizy nie zostać wykryte przez niedoświadczonego analityki biznesowego.
Bo on niby nie wie, że powinien o to zapytać, a klient traktuje to jako coś tak oczywistego, że zapomniał o tym wspomnieć.

Założenie, że wystarczy w jeden dzień klienta nauczyć czytać diagramy i po sprawie wydaje mi się zbyt optymistyczne. Może miałeś szczęście, a może masz talent do szybkiego nauczania wszystkich swoich klientów co i jak powinni czytać. Ale między czytaniem, a czytaniem ze zrozumieniem jest lekka różnica.

Kluczem w całej tej dyskusji, która poszła w kilku ciekawych kierunkach jest jednak "co użyć w stosunku do klienta", a nie co dać projektantom/programistom.

A to powoli zaczyna się robić dyskusja o wyższości Świąt Bożego Narodzenia nad Wielkanocą. Oba są ważne w swoim czasie. I tu się zgodzę - trzeba sobie odpowiedzieć na pytanie kiedy co użyć, by klient wiedział dokładnie o co chodzi. Nie my (chociaż po kilkunastu miesiącach nam się też przyda), lecz On.

Szczególnie w przypadkach zamówień publicznych, gdzie musi (powinien) w jakiś sposób formalny potwierdzić, że to co jest tutaj napisane jest tym co on chce uzyskać. Jeżeli ktoś mi podstawi dokument do podpisania po francusku, z dużą ilością obrazków to będą miał wątpliwość czy to na pewno chcę podpisać ...

Stanisław Niepostyn:

Dariusz G.:

No tak nie do końca. Nie zawsze opis procesu jest tożsamy z jego optymalizacją

Czy gdzieś tak napisałem ?

Skoro negujesz moje twierdzenie, że opis procesu może być prostszy niż jego optymalizacja, to tak właśnie napisałeś :).

A wydawało mi się, że napisałem, że opisywanie procesu jest trudniejsze, anizeli optymalizacja ;)
W takim razie bardzo przepraszam, że inaczej zinterpretowałeś moją wypowiedź, niezgodnie z moim zamiarem ;)

A ja nadal będę twierdził, ze optymalizacja może być dużo trudniejsza niż sam opis (modelowanie jak wolisz).

Wprost przeciwnie ;) W większości wdrożeń od razu przechodzi się do optymalizacji zupełnie nie zawracając sobie głowy aktualnym stanem. innymi słowy: wdrożamy tak jak w innych firmach (bo nam wygodnie), natomiast Klient sam musi się przystosować do naszej koncepcji wdrożenia. A jak chce wyliczyć jakieś współczynniki, czy parametry to jego sprawa. Nieprawdaż ?

A o jakich wdrożeniach i czego mówimy? Aktualny stan zastany jest bardzo istotny. Jeżeli wchodzisz do klienta i na dzień dobry mówisz "ja wiem lepiej" to współczuję. Klient niczego nie musi. Wdrożenie to wspólna praca, żeby były jakieś efekty. No chyba, że masz doświadczenia z sektora publicznego, gdzie namaszczone firmy wdrażają co chcą i jak chcą.

Jak Klient chce to mu jakąś tam analizę AS-IS na siłę zrobimy, ale my od razu przechodzimy do optymalizacji (czyli do modelu TO-BE), a więc przedstawiamy mu nasz "genaialny" plan wdrożenia i mówimy ile jeszcze musi wydać kasy, by móc ogłosic światu, że wdrożył nowoczesne technologie u siebie ;)

Dlatego też opis procesu wydaje się nam tak zdumiewająco prosty (po prostu zazwyczaj go nie robimy).
A to nie tak ;) Największy ból głowy, gdybyśmy uczciwie podeszli do optymalizacji procesów biznesowych, to znaczy najpierw wymyslili odpowiednie parametry procesu i sposób obliczania tych parametrów, nie mówiąc o samym modelu AS-IS (ale komu to potrzebne?).

Sorry, ale jakieś banialuki straszne Waćpan piszesz, bez ładu i składu. Do problemu podchodzi się w zależności od tego jaki jest to problem i jego skala, a nie zgodnie z tym, co w podręcznikach podają jako "modelowe podejście". U pani Kazi w kwiaciarni to może z biegu Symfonie wdrożysz, ale dużego ERP-a, CRM-a, etc. w międzynarodowej korporacji już niekoniecznie. A jak dochodzimy do pisania "na wymiar" to sprawy jeszcze się mogą skomplikować.

Przykładowo jak opisać proces, a nawet same jego parametry, gdybyśmy chcieli zoptymalizować proces obsługi faktur kosztowych pod kątem zmniejszenia kosztów na etaty osób tam zatrudnionych ?
Weź dowolny system IT i zawsze Ci wyjdzie, że wdrożenie dowolnego systemu informatycznego, by zredukować personel jest bardzo nieopłacalne i nieekonomiczne !!! Czemu więc firmy informatyzują swoją księgowość ?

Nie zawsze wyjdzie. Poza tym wdrażanie czegoś tylko po to żeby zredukować personel, to w 9/10 przypadków pewna porażka wdrożenia. Poza tym utożsamianie wdrożenia z redukcjami, to jakieś chore myślenie. Masz jakieś negatywne doświadczenia, czy jak?

Odpowiedz sobie na najprostsze z możliwych pytanie: Czemu do prowadzenia KPiR używa się programów, skoro można w książce pisać?

Poza tym obejrzyj sobie diagram, który Jarek wkleił, to będziesz miał całościowy obraz zagadnienia :). A reszta to już są niuanse, co do których nie ma jednego "słusznego" podejścia.

Aleksander Płaczek:

powiem tak: zgadzam się ze wszystkim co napisałeś i problem w tym, że trzeba jakoś temu dać radę.

Co do szkoleń, faktem jest, ze przyswajają różnie i nie jest to ich wina. Po wielu doświadczeniach, dochodzę do wniosku, ze od klienta nie należy oczekiwać niczego, poważanie. Od kilku lat ma wrażenie, że firmy informatyczne oczekują od klienta wejścia do gabinetu lekarza postawienia samemu diagnozy, taki selfservice, więc po co analityk/lekarz? W czym problem: w zaufaniu.

Bo on niby nie wie, że powinien o to zapytać, a klient traktuje to jako coś tak oczywistego, że zapomniał o tym wspomnieć.

i nie będzie nigdy wiedział...

Szczególnie w przypadkach zamówień publicznych, gdzie musi (powinien) w jakiś sposób formalny potwierdzić, że to co jest tutaj napisane jest tym co on chce uzyskać. Jeżeli ktoś mi podstawi dokument do podpisania po francusku, z dużą ilością obrazków to będą miał wątpliwość czy to na pewno chcę podpisać ...

Co zrobisz jak w potrzebie zamówienia tony bielizny w Chinach zlecisz za pieniądze tłumaczowi przełożenie swojego tekstu zamówienia na chiński? Sprawdzisz po nim (zakładam, ze nie znasz chińskiego;))? Nie, wybierasz tłumacza, któremu po protu musisz zaufać. Nie masz wyjścia...

Od pewnego czasu traktuje klientów właśnie jak tłumacz. Po co mi BPMN/UML? Bo te modele, jeśli są poprawnie wykonane, można testować tak samo jak model samolotu w tunelu aerodynamicznym...

po drugie praktyka uczy, że programista ma programować a nie projektować... więc trzeba mu dać projekt a nie pobożne życzenia...Jarek Żeliński edytował(a) ten post dnia 21.02.11 o godzinie 23:59

Jarek Żeliński:

Jacek Sałacki:

Dariusz G.:

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.

Oooooooooooo, a ja patrzę na specyfikację i widzę raptem siedem podstawowych plus opisy.... czy aby mowa o tym samym???
(dla ułatwienia: czynność, zdarzenie, sterowanie, komunikat, obiekt danych, bramka plus oznaczenia komentarzy)

Przepraszam, ale nie mogłem się powstrzymać, gdyż niedawno zakończyłem pracę nad edytorem BPMN, gdzie musiałem wielokrotnie edytować i przeszukiwać klasy z tymi "paroma" elementami. Toteż niniejszym pozwolę sobie podać wyłącznie wszystkie eventy i to w wersji trochę uboższej bo w wersji 1.2. Wersja 2.0 proponuje trochę więcej elementów BPMN.
Event
StartEvent
IntermediateEvent
EndEvent
StartMessage
StartTimer
StartNone
StartConditional
StartSignal
StartMultiple
EndMultiple
EndTerminate
EndSignal
EndCompensation
EndCancel
EndError
EndMessage
IntermediateMessageCatch
IntermediateMessageThrow
IntermediateTimer
IntermediateError
IntermediateCancel
IntermediateCompensationCatch
IntermediateCompensationThrow
IntermediateConditional
IntermediateLinkCatch
IntermediateLinkThrow
IntermediateSignalCatch
IntermediateSignalThrow
IntermediateMultipleCatch
IntermediateMultipleThrow

Stanisław Niepostyn:
Przepraszam, ale nie mogłem się powstrzymać, gdyż niedawno zakończyłem pracę nad edytorem BPMN, gdzie musiałem wielokrotnie edytować i przeszukiwać klasy z tymi "paroma" elementami.

owszem, skoro uważasz, że do sprawnego przekazywania myśli należy wykuć cały słownik języka polskiego i jego setki tysięcy haseł to Ty masz swoje teorie a ja swoją... pozostanę przy swojej... jak kogoś naszło na pisanie słownika ortograficznego, mimo że na rynku jest ich już zatrzęsienie to podziwiam jednak pisanie słownika a pisanie jako takie to dwie różne umiejętności...

ja dla ochłody przytoczę BPMN Core Elements:
http://www.omg.org/bpmn/Samples/Elements/Core_BPMN_Ele...
tego uczę klientów by coś kumali z dokumentów, działa...Jarek Żeliński edytował(a) ten post dnia 22.02.11 o godzinie 00:34

Dariusz G.:

Stanisław Niepostyn:

Dariusz G.:

No tak nie do końca. Nie zawsze opis procesu jest tożsamy z jego optymalizacją

Czy gdzieś tak napisałem ?

Skoro negujesz moje twierdzenie, że opis procesu może być prostszy niż jego optymalizacja, to tak właśnie napisałeś :).

A wydawało mi się, że napisałem, że opisywanie procesu jest trudniejsze, anizeli optymalizacja ;)
W takim razie bardzo przepraszam, że inaczej zinterpretowałeś moją wypowiedź, niezgodnie z moim zamiarem ;)

A ja nadal będę twierdził, ze optymalizacja może być dużo trudniejsza niż sam opis (modelowanie jak wolisz).

Ciesze się, że masz swoje odrębne zdanie :)

Wprost przeciwnie ;) W większości wdrożeń od razu przechodzi się do optymalizacji zupełnie nie zawracając sobie głowy aktualnym stanem. innymi słowy: wdrożamy tak jak w innych firmach (bo nam wygodnie), natomiast Klient sam musi się przystosować do naszej koncepcji wdrożenia. A jak chce wyliczyć jakieś współczynniki, czy parametry to jego sprawa. Nieprawdaż ?

A o jakich wdrożeniach i czego mówimy? Aktualny stan zastany jest bardzo istotny. Jeżeli wchodzisz do klienta i na dzień dobry mówisz "ja wiem lepiej" to współczuję. Klient niczego nie musi. Wdrożenie to wspólna praca, żeby były jakieś efekty. No chyba, że masz doświadczenia z sektora publicznego, gdzie namaszczone firmy wdrażają co chcą i jak chcą.

Ja to widzę i często nad tym boleję.
Ale też i bardzo się cieszę, że istnieją jednak firmy, które poważnie podchodzą do wdrozeń systemów informatycznych :)

Jak Klient chce to mu jakąś tam analizę AS-IS na siłę zrobimy, ale my od razu przechodzimy do optymalizacji (czyli do modelu TO-BE), a więc przedstawiamy mu nasz "genaialny" plan wdrożenia i mówimy ile jeszcze musi wydać kasy, by móc ogłosic światu, że wdrożył nowoczesne technologie u siebie ;)

Dlatego też opis procesu wydaje się nam tak zdumiewająco prosty (po prostu zazwyczaj go nie robimy).
A to nie tak ;) Największy ból głowy, gdybyśmy uczciwie podeszli do optymalizacji procesów biznesowych, to znaczy najpierw wymyslili odpowiednie parametry procesu i sposób obliczania tych parametrów, nie mówiąc o samym modelu AS-IS (ale komu to potrzebne?).

Sorry, ale jakieś banialuki straszne Waćpan piszesz, bez ładu i składu. Do problemu podchodzi się w zależności od tego jaki

Fajnie, że przejrzałeś mój dość ironiczny tekst, ale ... niestety takie dokuemtacje zostawiają po sobie duże firmy IT ...

jest to problem i jego skala, a nie zgodnie z tym, co w podręcznikach podają jako "modelowe podejście". U pani Kazi w kwiaciarni to może z biegu Symfonie wdrożysz, ale dużego ERP-a, CRM-a, etc. w międzynarodowej korporacji już niekoniecznie. A jak dochodzimy do pisania "na wymiar" to sprawy jeszcze się mogą skomplikować.

Chodzi o to, że Klientowi pokazujemy często tylko model, w którym Pani Kazia wciska klawisz, a system drukuje paragonik. Nie pokazujemy najpierw jednego modelu, w którym Pani Kazia bierze długopis i pisze cos w zeszycie, a później wystawia ręcznie paragonik, tylko od razu ten modelik z klawiszem i wydrukiem ...

Przykładowo jak opisać proces, a nawet same jego parametry, gdybyśmy chcieli zoptymalizować proces obsługi faktur kosztowych pod kątem zmniejszenia kosztów na etaty osób tam zatrudnionych ?
Weź dowolny system IT i zawsze Ci wyjdzie, że wdrożenie dowolnego systemu informatycznego, by zredukować personel jest bardzo nieopłacalne i nieekonomiczne !!! Czemu więc firmy informatyzują swoją księgowość ?

Nie zawsze wyjdzie. Poza tym wdrażanie czegoś tylko po to żeby

Podaj przykład, że nie zawsze wyjdzie ... straszniem ciekaw ....

zredukować personel, to w 9/10 przypadków pewna porażka wdrożenia. Poza tym utożsamianie wdrożenia z redukcjami, to jakieś chore myślenie. Masz jakieś negatywne doświadczenia, czy jak?

Jedna z większych firm, by zareklamować swój produkt opracowała kalkulator ROI, w którym dla AS-IS jest ileś tam personelu, a w TO-BE jest o wiele mniej, bo ich produkt oczywiście robi szybciej i dokładniej. ROI rosło, bo było mniej personelu, ale w konkluzji zaznaczono, ze tych ludzi można z powodzeniem zatrudnic na innych stanowiskach.

z drugiej strony firmy się przekonuja, że wraz z wdrożeniem systemu informatycznego zatrudnienie wzrasta, a nie malej ... taki mały paradoks, prawda ?

Odpowiedz sobie na najprostsze z możliwych pytanie: Czemu do prowadzenia KPiR używa się programów, skoro można w książce pisać?

No jak ktoś jest na ryczałcie to chyba musiałby być nieźle nakręcony, by używać do tego programu, zwłaszcza jak nie ma zbyt licznych operacji

Poza tym obejrzyj sobie diagram, który Jarek wkleił, to będziesz miał całościowy obraz zagadnienia :). A reszta to już są niuanse, co do których nie ma jednego "słusznego" podejścia.