Temat: Modelowanie czy rysowanie

Marek K.:
Jeżeli o mnie chodzi to w praktyce staram się operować słowem i ujmować to co narysowane w formie procedur i instrukcji.

Ja jakos obrazkowy jestem i od prozy wole ryzunek :)

"Wredność" zarówno dyrektorów jak i szeregowych pracowników jest taka, że odbija się czkawką wszystko to co nie jest czarno na białym napisane: masz robić tak i tak. A rysunek? Wystarczy schemat organizacyjny. Rysunek obśmieją, bo jak ktoś "dał ciała" i jest konfliktowa sytuacja to zawsze padają argumenty, a gdzie to jest napisane, że mam robić tak i tak. :-(((

O tak, ale to można narysować... co do BPMN, osobiście uważam, ze "tego" sie nie sprzedaje, "tego" sie używa np. zamiast prozy...

:)

Temat: Modelowanie czy rysowanie

[author]Jarosław

Link do wypowiedzi

Temat: Modelowanie czy rysowanie

Problem w tym, że temat poważny, więc trzeba mocno przysiąść aby przeanalizować co było napisane i wgłębić się w temat. A ja aż tule czasu teraz nie mam.

No ale przynajmniej zasygnalizuje swoje wątpliwości.

1. BPMN łamie poprzednie standardy opisu procesów (ANSI, SIPOC) wprowadzając zdarzenia do opisu "wykonania procesu". Nawiasem mówiąc, co to jest wykonanie procesu?

- Zdarzenia nie należą do procesu, nie mogą należeć, gdyż proces to przetwarzanie, a nie bieg wydarzeń! Zdarzenia mogą należeć do ontologicznego porządku sterowania procesem, ale nie do procesu.

- Proces - ten w fabryce albo w biurze - to nie bieg wydarzeń lecz sekwencja operacji przetwarzania (ang. processing). Proces to nie sekwencja instrukcji do wykonania (program).

----

Mam nadzieję, że widać już co się porobiło.

Proces pomylono z programem.
============================

Dlaczego albo po co pomylono? A no bo za projektowanie procesów wzięli się informatycy, wraz ze swoimi różnorakimi "guru". I oni nie projektują procesów, tak jak projektuje to zawodowiec czyli inżynier przemysłowy. Oni piszą program dla komputera i dla człowieka korzystającego z komputera.

No i dziwią się że to nie działa. Że człowiek wcale nie "wykonuje" programu, tylko robi to, co chce robić.

(Wyjaśniam. Tzw workflow czyli kolejka zadań ustawiona człowiekowi do wykonania przez ten cały BPM, otóż workflow nie działa, chyba że łupnie się kary pieniężne wszystkim, którzy się nie podporządkują. Czyli dokładnie tak, jak w każdym innym najgorszym sposobie zarządzania.)

Co gorsza, większość tych "projektów" które widziałem, to programy pełne pluskiew, jak każdy kiepski program. Niedowiarkom proponuję zajrzeć do angielskojęzycznej Wikipedii i UWAŻNE przejrzenie tych RYSUNKÓW, które można znaleźć tam i w linkach z tamtej strony. Nawet człek nie zorientowany w procesach bez trudu zauważy dowolności, niekonsekwencje itd.

=========
2. Dlaczego komputer ma zastępować człowieka w decydowaniu? NO DLACZEGO? Zapytuję ponieważ nie widzę w tym sensu, a w zamian widzę zagrożenie syndromem Wielkiego Brata. Przeczołgałem na tę okoliczność jednego z głównych "guru" Ismaela Ghalimi, jak zwykle bez osobistej satysfakcji. No ale Ismael nie potrafił odpowiedzieć na tak podstawowe pytanie o przesłankę jednego z fundamentalnych założeń tej całej zabawy w BPMN.

==========

3. Z systemami też nie jest lepiej. Dlaczego na przykład "modeluje" się coś tam w postaci drzewa (patrz rysunki powyżej), a następnie udaje się, że to model organizacji albo hierarchii procesów albo czegoś tam jeszcze? A co z organizacjami o strukturze sieci (budownictwo) albo pierścienia (korporacje handlowe np. w Azji, czy dawne centra przemysłowo-rolnicze na Śląsku)?

Wcale nie dlatego, że hierarchia jest właściwym modelem organizacji. Zresztą coraz mniej jest w dobie organizacji macierzowych.

Otóż dlatego - jak przypuszczam - że informatycy natrafiają na podstawową trudność (zagadnienie identyfikatora), która zmusza ich do rejestracji wszystkich pracujących zasobów systemu informatycznego w jednym miejscu. Oczywiście przy odrobinie wyobraźni mogliby uwolnić się od tego ograniczenia w warstwach bliskich Użytkownikowi (jak ja to robię w niektórych swoich witrynach interenetowych). Ale do tego trzeba znać dobrze modelowany przedmiot, a oni nie znają, tylko biorą z sufitu (co to jest model procesowy organizacji? To obraz jak sobie organizację wyobraża projektant).

System musi mieć pętle w swojej topologii. Pętle sprzężeń. Inaczej nie jest systemem.

Oczywiście powyższe nie jest krytyką gremialną, tylko krytyką wybranych podejść jakie można zaobserwować w pracach informatyków.

No dobra, wracam do roboty. See U!

:)

Temat: Modelowanie czy rysowanie

Andrzej G.:
Problem w tym, że temat poważny, więc trzeba mocno przysiąść aby przeanalizować co było napisane i wgłębić się w temat.

:-D

No ale przynajmniej zasygnalizuje swoje wątpliwości.

:-D

1. BPMN łamie poprzednie standardy opisu procesów (ANSI, SIPOC) wprowadzając zdarzenia do opisu "wykonania procesu".

Zagrożeń nie widzę a wręcz przeciwnie możliwość zbliżenia opisu do rzeczywistości. Zmiana, incydent to zdarzenia, często o losowym charakterze, skutecznie zakłócające najlepiej zaplanowany proces. Dobrze więc, że w modelowaniu zaczęto dostrzegać także potrzebę zarządzania zmianą i zarządzania incydentem.

Nawiasem mówiąc, co to jest wykonanie procesu?

No tak z terminologią to to środowisko ma na bakier nie od dziś.

- Zdarzenia nie należą do procesu, nie mogą należeć, gdyż proces to przetwarzanie, a nie bieg wydarzeń!

Dlaczego nie mogą? Przecież jak coś się zdarzy to trzeba na to zareagować, przetworzyć?

Zdarzenia mogą należeć do ontologicznego porządku sterowania procesem, ale nie do procesu.

Zaraz, jeżeli w ramach procesu przewidujemy możliwość wystąpienia jakiś zdarzeń, może być że losowych, to ja to zliczyłbym do procesu. Odrębne zagadnienie to opis sterowania procesem ale to zaliczyłbym do warstwy meta.

- Proces - ten w fabryce albo w biurze - to nie bieg wydarzeń lecz sekwencja operacji przetwarzania (ang. processing). Proces to nie sekwencja instrukcji do wykonania (program).

OK, no to weźmy przykład, proces obsługi reklamacji klienta. Np: 1. Odebrać tel/faks/mail; 2. Ująć w ewidencji, nadać numer; 3. Wysłać kuriera; 4. Odebrać przesyłkę; 5. Wykonać usługę reklamacyjną; 6. Udokumentować; 7. Odesłać.

Przetwarzanie przeplata się z wykonaniem. Czyli proces to to i to. Aby rozpisać to na konkretne działania, osoby potrzebna jest instrukcja.

Mam nadzieję, że widać już co się porobiło.
Proces pomylono z programem.
============================

Zbyt pośpieszny wniosek.

Dlaczego albo po co pomylono? A no bo za projektowanie procesów wzięli się informatycy, wraz ze swoimi różnorakimi "guru". I oni nie projektują procesów, tak jak projektuje to zawodowiec czyli inżynier przemysłowy. Oni piszą program dla komputera i dla człowieka korzystającego z komputera.

Nie posiadam wiedzy pozwalającej ustosunkować się do tego.

No i dziwią się że to nie działa. Że człowiek wcale nie "wykonuje" programu, tylko robi to, co chce robić.

Dziwią się kiepscy modelarze. Ale dlaczego wszyscy mają się dziwić?

(Wyjaśniam. Tzw workflow czyli kolejka zadań ustawiona człowiekowi do wykonania przez ten cały BPM, otóż workflow nie działa, chyba że łupnie się kary pieniężne wszystkim, którzy się nie podporządkują. Czyli dokładnie tak, jak w każdym innym najgorszym sposobie zarządzania.)

To też dotyczy tych second-hand.

Co gorsza, większość tych "projektów" które widziałem, to programy pełne pluskiew, jak każdy kiepski program. Niedowiarkom proponuję zajrzeć do angielskojęzycznej Wikipedii i UWAŻNE przejrzenie tych RYSUNKÓW, które można znaleźć tam i w linkach z tamtej strony. Nawet człek nie zorientowany w procesach bez trudu zauważy dowolności, niekonsekwencje itd.

Nie kwestionuję, ale to krytyka konkretnych osób. My natomiast raczej nie powinniśmy mieszać teorii z praktyką.

=========
2. Dlaczego komputer ma zastępować człowieka w decydowaniu? NO DLACZEGO?

No nie, podejmuję rękawicę! :-D

Zapytuję ponieważ nie widzę w tym sensu, a w zamian widzę zagrożenie syndromem Wielkiego Brata.

Sens jest, a zagrożenie syndromem Wielkiego Brata dotyczy nie tylko tego zagadnienia lecz całej IT więc to pominę. Co do dyskusji o sensie już lecę po kask. :-D

Przeczołgałem na tę okoliczność jednego z głównych "guru" Ismaela Ghalimi, jak zwykle bez osobistej satysfakcji. No ale Ismael nie potrafił odpowiedzieć na tak podstawowe pytanie o przesłankę jednego z fundamentalnych założeń tej całej zabawy w BPMN.

OK. Już się w dres przebrałem! Gotów :-D

Przede wszystkim, modelowania systemów IT nie wolno zawężać tylko i wyłącznie do systemów biznesowych. Jak modelowanie przez IT to modelowanie dowolnych systemów informatycznych. To na początek.

Zastępowanie człowieka w decydowaniu po co? Już 2o lat temu jak pisałem na ten temat to wykaz nazw systemów zajmujących się decydowaniem obejmował kilka kartek i daleko mu było do kompletności. Ale wracamy do meritum. Po co? - bo człowiek:
- jest leniwy, omylny,
- należy mu się odpoczynek,
- jego życie jest coś warte,
- wiedza specjalistyczna nie jest dostępna wszystkim,
- nie wszyscy na wszystkim się znają,
- .. .
A przykłady zastosowań:
- rezerwacja biletów lotniczych: decydowanie o wyborze trasy (przesiadki), niskiej cenie biletu, czasie trawnia podróży i to wszystko wychodząc od oczekiwanej daty/godziny przylotu i/lub odlotu, miejscu, ..;
- doradztwo, dowolnej maści, 24 godz/doba;
- sterowanie trasą przelotu pocisków sterowanych z omijaniem przeszkód również w warunkach intensywnych działań wojennych ze strony nieprzyjaciela;
- MYCIN, INTERNIST, ..., porady lekarskie dla osób przebywających w rejonach o utrudnionym dostępie do lekarzy, np: wśród eskimosów, na jachcie płynącym przez ocean, ..;
- w firmie produkcyjnej, gdzie często potrzebna może być wiedza dostępna tylko konstruktorom, projektantom jakiegoś urządzenia (pakiet elektroniki, silnik samochodu, ..);
- ..

Spokojnie, nie chodzi o odbieranie chleba ekspertom, choć pseudo-eksperci mogą mieć przechlapane.

Jakie pole przeoraliśmy to już chyba wiadomo, sztuczna inteligencja AI.

Pamiętam jak po 3 latach leżenia maszynopisu mojej pracy u prof. Krzysztofa Badźmirowskiego, kiedyś mówi do mnie tak. Panie Marku, to co Pan napisał to jest takie proste i oczywiste ale jak czytam co wypisują moi koledzy profesorowie, to mam propozycję, opublikujmy to. Posiedzieliśmy "troszkę" razem i z tego co wiem prof. Jan Mulawka wykorzystał to jako uzupełniający podręcznik dla studentów.

Dzisiaj jak patrzę na modelowanie systemów to zbędna wydaje się moja polemika z profesorem o tytuł książki: systemy doradcze czy systemy ekspertowe?

Skłonny jestem propagować taki podział:
systemy doradcze - udostępnianie wiedzy o charakterze biznesowym,
systemy ekspertowe - udostępnianie wiedzy o charakterze naukowym.
Póki co nie upieram się przy powyższym.

==========
3. Z systemami też nie jest lepiej. Dlaczego na przykład "modeluje" się coś tam w postaci drzewa (patrz rysunki powyżej), a następnie udaje się, że to model organizacji albo hierarchii procesów albo czegoś tam jeszcze? A co z organizacjami o strukturze sieci (budownictwo) albo pierścienia (korporacje handlowe np. w Azji, czy dawne centra przemysłowo-rolnicze na Śląsku)?

Stop. Struktura organizacji może być drzewem, może też być siecią czy pierścieniem. To nie ma znaczenia. Modelujemy przecież procesy.

Procesy natomiast są odzwierciedleniem przepływu informacji. Ograniczmy się tu do IT w biznesie. Informacji towarzyszą dokumenty, a te jako obiekt szczególnego znaczenia dla różnej maści kontrolerów, włącznie z policją skarbową, nie mogą zniknąć i zawsze musi być wiedza gdzie są. Dokument zaś aby spełnić powyższe warunki trzeba przekazywać z rąk do rąk. Choćby więc nie wiem jak zagmatwana była struktura i organizacja to proces ich przekazywania musi przebiegać po sznurku. A czymże jest takie przekazywanie dokumentu z rąk do rąk jak nie chodzeniem po grafie? Toż to wszystko musi być udokumentowane aby było przejrzyste i weryfikowalne.

No i kolejny aspekt. Każde przedsiębiorstwo, uporządkowane lub nie, gdzieś ma swoje siedziby, zatrudnia konkretną ilość pracowników, ma plany kokretnych przejęć albo redukcji i to wszystko stanowi zamkniętą przestrzeń poszukiwania dla modelującego. Jak on się po tym porusza, czy wie co to jest problem komiwojażera, to tylko zależy od jego wiedzy. Niezależnie jednak czy jest tego świadom czy nie, osoba ta zabierając się do pracy coś zakłada i tym samym posługuje się wnioskowaniem wstępującym albo zstępującym. Jak niekonsekwentny to oboma naraz i efekty takie jak wyżej - nic tylko czołganiem przez pełzanie pogonić.

Wcale nie dlatego, że hierarchia jest właściwym modelem organizacji. Zresztą coraz mniej jest w dobie organizacji macierzowych.

Na ten temat już było.

Otóż dlatego - jak przypuszczam - że informatycy natrafiają na podstawową trudność (zagadnienie identyfikatora), która zmusza ich do rejestracji wszystkich pracujących zasobów systemu informatycznego w jednym miejscu.

No nie, bo są systemy rozproszone ale programowanie systemów wieloprocesowych i wieloprocesorowych to wyższa szkoła jazdy.

Oczywiście przy odrobinie wyobraźni mogliby uwolnić się od tego ograniczenia w warstwach bliskich Użytkownikowi (jak ja to robię w niektórych swoich witrynach interenetowych). Ale do tego trzeba znać dobrze modelowany przedmiot, a oni nie znają, tylko biorą z sufitu (co to jest model procesowy organizacji? To obraz jak sobie organizację wyobraża projektant).

Czołganiem przez pełzanie ... :-(((

System musi mieć pętle w swojej topologii. Pętle sprzężeń. Inaczej nie jest systemem.

Oczywiście mowa o ujemnym sprzężeniu zwrotnym, bo tylko takie zapewnia stabilność rozwiązań systemowych.

Oczywiście powyższe nie jest krytyką gremialną, tylko krytyką wybranych podejść jakie można zaobserwować w pracach informatyków.

No i za to Pana lubię. :-D

Temat: Modelowanie czy rysowanie

Marek K.:

Zagrożeń nie widzę a wręcz przeciwnie możliwość zbliżenia opisu do rzeczywistości.

Na prawdę zbliżenia? Jeśli zaciera się różnicę pomiędzy dodawaniem a upadkiem kalkulatora na podłogę?

Zmiana, incydent to zdarzenia, często o losowym charakterze, skutecznie zakłócające najlepiej zaplanowany proces. Dobrze więc, że w modelowaniu zaczęto dostrzegać także potrzebę zarządzania zmianą i zarządzania incydentem.

Czyżby i Pan również podwiązywał się pod starą i doskonale sprawdzoną techniką odmrażania sztywnej organizacji, opisaną bodajże w 1912 roku przez Kurta Lewina?

No już dobrze, przestaję. Ale proszę mi powiedzieć, według jakich zasad sterowania procesami odbywa się to "zarządzanie zmianą"? A także zarządzanie incydentem?

Bo wie Pan, techniki zapewnienia stabilności procesów dość dawno radzą sobie z zakłóceniami, bez potrzeby mnożenia bytów (incydent).

Nawiasem mówiąc, co to jest wykonanie procesu?

No tak z terminologią to to środowisko ma na bakier nie od dziś.

Przecież to nie jest błąd terminologiczny, tylko całkiem świadomy przekręt terminologiczny.

- Zdarzenia nie należą do procesu, nie mogą należeć, gdyż proces to przetwarzanie, a nie bieg wydarzeń!

Dlaczego nie mogą? Przecież jak coś się zdarzy to trzeba na to zareagować, przetworzyć?

W jaki sposób przetwarza się zdarzenia? Jaki jest produkt takiego procesu?

Zdarzenia mogą należeć do ontologicznego porządku sterowania procesem, ale nie do procesu.

Zaraz, jeżeli w ramach procesu przewidujemy możliwość wystąpienia jakiś zdarzeń, może być że losowych, to ja to zliczyłbym do procesu.

A ja bym zaliczył do nieszczęścia pechowca. Na prawdę proszę nie wprowadzać dowolności! Proces ma określoną ścisłą definicję, jak trójkąt w geometrii.

Odrębne zagadnienie to opis sterowania

procesem ale to zaliczyłbym do warstwy meta.

Warstwa meta dotyczy dokumentu - to ta część treści dokumentu, która dotyczy jego samego. Nawet szukając dalekich analogii trudno byłoby powiedzieć że mamy proces, którego część przetwarza tenże sam proces.

OK, no to weźmy przykład, proces obsługi reklamacji klienta. Np: 1. Odebrać tel/faks/mail; 2. Ująć w ewidencji, nadać numer; 3. Wysłać kuriera; 4. Odebrać przesyłkę; 5. Wykonać usługę reklamacyjną; 6. Udokumentować; 7. Odesłać.

To jest instrukcja obsługi reklamacji, a nie proces. Czy instrukcja przeciwpożarowa opisuje proces?

A w powyższym wypadku proces może wyglądać na przykład tak:

Andrzej Odbiera fax
Andrzej rejestruje faz w dzienniku korespondencji (podawczym)
Sprawa czeka (Andrzej je śniadania bo akurat jest przerwa śniadaniowa)
Sprawa czeka (Andrzej telefonuje po kuriera.)
Sprawa czeka (Wszyscy czekają na kuriera. Agnieszka wyrywa się głupia i mowi, że sama dawno by już dostarczyła przesyłkę gdzie trzeba. Szef ją strofuje i odsyła do lektury procedur)
Kurier podejmuje przesyłkę
Kurier transportuje przesyłkę
... itd.

Żelazna zasada: proces opisuje się w trzeciej osobie liczby pojedynczej, w trybie orzekającym. A nie w trybie rozkazującym, jak instrukcję.

Andrzej czeka na kuriera ponieważ jest akurat przerwa obiado

Przetwarzanie przeplata się z wykonaniem.

Jak reprezentowane jest owo "przeplatanie się"? To jakaś relacja, czy sekwencja, czy co?

Czyli proces to to i to.

I to, i to? I co jeszcze? A jak pada deszcz (zdarzenie) i przesyłka na nim moknie to też? A jak przyjdzie następny geniusz modelowania i doda zaćmienia Księżyca?

Aby rozpisać to na konkretne działania, osoby potrzebna jest instrukcja.

Instrukcja określa standard pracy, jest ciągiem rozkazów. Czy proces składa się z rozkazów? Co jest przetwarzane przez rozkaz? Co jest przetwarzane przez instrukcję?

(to jest ważne pytanie, odpowiedź powinna wiele wyjaśnić)

Instrukcja należy zatem do sterowania, a nie do procesu.

Mam nadzieję, że widać już co się porobiło.
Proces pomylono z programem.
============================

Zbyt pośpieszny wniosek.

Spoko :) Wypracowany w toku wielu miesięcy dyskusji z na prawdę poważnymi fachowcami.

2. Dlaczego komputer ma zastępować człowieka w decydowaniu? NO DLACZEGO?

No nie, podejmuję rękawicę! :-D
Co do dyskusji o sensie już lecę po kask. :-D
OK. Już się w dres przebrałem! Gotów :-D

Przede wszystkim, modelowania systemów IT nie wolno zawężać tylko i wyłącznie do systemów biznesowych. Jak modelowanie przez IT to modelowanie dowolnych systemów informatycznych. To na początek.

Zastępowanie człowieka w decydowaniu po co? Już 2o lat temu jak pisałem na ten temat to wykaz nazw systemów zajmujących się decydowaniem obejmował kilka kartek i daleko mu było do kompletności. Ale wracamy do meritum. Po co? - bo człowiek:
- jest leniwy, omylny,
- należy mu się odpoczynek,
- jego życie jest coś warte,
- wiedza specjalistyczna nie jest dostępna wszystkim,
- nie wszyscy na wszystkim się znają,
- .. .
A przykłady zastosowań:
- rezerwacja biletów lotniczych: decydowanie o wyborze trasy (przesiadki), niskiej cenie biletu, czasie trawnia podróży i to wszystko wychodząc od oczekiwanej daty/godziny przylotu i/lub odlotu, miejscu, ..;
- doradztwo, dowolnej maści, 24 godz/doba;
- sterowanie trasą przelotu pocisków sterowanych z omijaniem przeszkód również w warunkach intensywnych działań wojennych ze strony nieprzyjaciela;
- MYCIN, INTERNIST, ..., porady lekarskie dla osób przebywających w rejonach o utrudnionym dostępie do lekarzy, np: wśród eskimosów, na jachcie płynącym przez ocean, ..;
- w firmie produkcyjnej, gdzie często potrzebna może być wiedza dostępna tylko konstruktorom, projektantom jakiegoś urządzenia (pakiet elektroniki, silnik samochodu, ..);
- ..

Takie i podobne historyjki słyszę od ok. 30 lat (zaraz zaraz ile to będzie? 28!)

Ale o nich później, bo należałoby po kolei omówić osiągnięcia oraz manowce.

Teraz tylko nadmienię, że system rezerwacji działa jedynie pod warunkiem, że klient zauważy iż data ze sprawdzania wolnych miejsc nie przenosi się do aplikacji rezerwującej. W przeciwnym razie czapa, będzie miał bilet na inną datę :D. Serio.

Spokojnie, nie chodzi o odbieranie chleba ekspertom, choć pseudo-eksperci mogą mieć przechlapane.

Prawdziwy ekspert i tak się nie przestraszy. Bo prawdziwy ekspert w każdej chwili może się przerzucić na obszary jeszcze nie opanowane przez... itd.

(Prawdziwi kowboje ponadto nie oglądają się za siebie)

No i wiedziałem, ze mnie Pan wyciągnie na spytki. Już muszę przerwać, bo jutro jeszcze dłubanina przy interfejsach... bleee

Temat: Modelowanie czy rysowanie

Andrzej G.:

No nie! Panie Andrzeju snu Panu odbierać nie chciałem ale dziękuję za dyskusję i mam nadzieję, że skoro dziś niedziela to można będzie trochę odpocząć. :-D

Marek K.:
Zagrożeń nie widzę a wręcz przeciwnie możliwość zbliżenia opisu do rzeczywistości.

Na prawdę zbliżenia? Jeśli zaciera się różnicę pomiędzy dodawaniem a upadkiem kalkulatora na podłogę?

Przeciw takim działaniom też protestuję. Co ma piernik do wiartaka.

W swoim myśleniu przywoływałem raczej sytuację, kiedy wynik dodawania dociera do nas w sytuacji kiedy zajmujemy się czymś innym niż dodawanie a z racji znaczenia tegoż powinniśmy na przekazany nam rezultat zareagować. Ot, dodawanie uruchomiliśmy jako proces asynchroniczny, który trwa tyle ile trwa, my w tym czasie zajmujemy się swoimi sprawami, a jak Ci co dodają są gotowi zgłaszają się do nas z wynikiem.

Nie podlega wątpliwości, że synchroniczne działania pozwalają nam na bardzo dobre porządkowanie, ale w świecie realnym non stop jesteśmy atakowani przez zaskoczenie. Lepiej więc nie udawać, że my to się podejść nie damy i mieć śwaidomość potrzeby także asynchronicznych działań.

Zmiana, incydent to zdarzenia, często o losowym charakterze, skutecznie zakłócające najlepiej zaplanowany proces. Dobrze więc, że w modelowaniu zaczęto dostrzegać także potrzebę zarządzania zmianą i zarządzania incydentem.

Czyżby i Pan również podwiązywał się pod starą i doskonale sprawdzoną techniką odmrażania sztywnej organizacji, opisaną bodajże w 1912 roku przez Kurta Lewina?

Teorii action research dokładnie nie znam ale nie jest chyba ona zbyt kontrowersyjna. Z koniecznością szanowania własnych poglądów ludzi w organizacji zgadzan się. :-D

No już dobrze, przestaję. Ale proszę mi powiedzieć, według jakich zasad sterowania procesami odbywa się to "zarządzanie zmianą"? A także zarządzanie incydentem?

Bo wie Pan, techniki zapewnienia stabilności procesów dość dawno radzą sobie z zakłóceniami, bez potrzeby mnożenia bytów (incydent).

Zasady są takie same więc z krytyczną uwagą mnożenia niepotrzebnych bytów zgadzam się, pod warunkiem, że w konkretnej sytuacji są one zbędne. Jeżeli zarządzającym nie jest obce myślenie zorientowane na rezultat to zbędnej redundancji nie wprowadzą. To też jest sposób właściwego zarządzania identyfikacją.

Wszystko to ma jednak jeszcze inny wymiar, wymiar praktyczny. Trzeba to jeszcze przełożyć na konkretne polecenia, instrukcje, które będą zrozumiałe dla każdego pracownika. W sferze edukacji, uświadamiania powyższe terminy dla mnie mają niebagatelne znaczenie porządkujące.

Nawiasem mówiąc, co to jest wykonanie procesu?

No tak z terminologią to to środowisko ma na bakier nie od dziś.

Przecież to nie jest błąd terminologiczny, tylko całkiem świadomy przekręt terminologiczny.

Przekrętów nie popieram.

- Zdarzenia nie należą do procesu, nie mogą należeć, gdyż proces to przetwarzanie, a nie bieg wydarzeń!

Dlaczego nie mogą? Przecież jak coś się zdarzy to trzeba na to zareagować, przetworzyć?

W jaki sposób przetwarza się zdarzenia? Jaki jest produkt takiego procesu?

Fakt takiego samego postępowania podczas obsługi procesu jak i zdarzenia, dla mnie osobiście nie dyskredytuje przydatności tej terminologii, tak samo jak to, że program obsługi przerwania jest pisany z wykorzystaniem tych samych zasad jak i program główny. Przerwanie to przerwanie tak jak i funkcja jest funkcją a procedura procedurą. Zyskujemy na przejrzystości, zrozumiałości, itd. itp., oczywiście pod warunkiem, że nie wezmą się za to niedouczeni.

Zdarzenia mogą należeć do ontologicznego porządku sterowania procesem, ale nie do procesu.

Zaraz, jeżeli w ramach procesu przewidujemy możliwość wystąpienia jakiś zdarzeń, może być że losowych, to ja to zliczyłbym do procesu.

A ja bym zaliczył do nieszczęścia pechowca. Na prawdę proszę nie wprowadzać dowolności! Proces ma określoną ścisłą definicję, jak trójkąt w geometrii.

OK, ale modelując poza sterowaniem i procesem dobrze też pamiętać o możliwości zdarzenia się nieszczęścia. Porządek sterowania procesem trzeba jakoś opisać.

Odrębne zagadnienie to opis sterowania procesem ale to zaliczyłbym do warstwy meta.

Warstwa meta dotyczy dokumentu - to ta część treści dokumentu, która dotyczy jego samego. Nawet szukając dalekich analogii trudno byłoby powiedzieć że mamy proces, którego część przetwarza tenże sam proces.

Też prawda. Ale to akurat odsłania złożoność problemu.

OK, no to weźmy przykład, proces obsługi reklamacji klienta. Np: 1. Odebrać tel/faks/mail; 2. Ująć w ewidencji, nadać numer; 3. Wysłać kuriera; 4. Odebrać przesyłkę; 5. Wykonać usługę reklamacyjną; 6. Udokumentować; 7. Odesłać.

To jest instrukcja obsługi reklamacji, a nie proces. Czy instrukcja przeciwpożarowa opisuje proces?

W ogólności oczywiście.

A w powyższym wypadku proces może wyglądać na przykład tak:
Andrzej Odbiera fax
Andrzej rejestruje faz w dzienniku korespondencji (podawczym)
Sprawa czeka (Andrzej je śniadania bo akurat jest przerwa śniadaniowa)
Sprawa czeka (Andrzej telefonuje po kuriera.)
Sprawa czeka (Wszyscy czekają na kuriera. Agnieszka wyrywa się głupia i mowi, że sama dawno by już dostarczyła przesyłkę gdzie trzeba. Szef ją strofuje i odsyła do lektury procedur)
Kurier podejmuje przesyłkę
Kurier transportuje przesyłkę
... itd.

Nie chcę się spierać czy to proces czy to też instrukcja bo nie jest to najistotniejsze choć bardzo ważne. Dopiero spojrzenie na całość dokumentacji może dać nam właściwy pogląd czy nie popełniamy błędu.

Żelazna zasada: proces opisuje się w trzeciej osobie liczby pojedynczej, w trybie orzekającym. A nie w trybie rozkazującym, jak instrukcję.

Kupuję! 3 os. l.poj zawsze była przeze mnie wyróżniana. :-D

Andrzej czeka na kuriera ponieważ jest akurat przerwa obiado

Przetwarzanie przeplata się z wykonaniem.

Jak reprezentowane jest owo "przeplatanie się"? To jakaś relacja, czy sekwencja, czy co?

Czyli proces to to i to.

I to, i to? I co jeszcze? A jak pada deszcz (zdarzenie) i przesyłka na nim moknie to też? A jak przyjdzie następny geniusz modelowania i doda zaćmienia Księżyca?

Geniuszów pomijamy natomiast przesyłka na deszczu moknąć nie może, więc zdarzenie pada deszcz powinno, jeżeli jest taka rzeczywista potrzeba, być obsłużone. Opis może mieć charakter opisu procesu ale nie udowadnia to błędności nazywania opadu deszczu zdarzeniem.

Aby rozpisać to na konkretne działania, osoby potrzebna jest instrukcja.

Instrukcja określa standard pracy, jest ciągiem rozkazów. Czy proces składa się z rozkazów? Co jest przetwarzane przez rozkaz? Co jest przetwarzane przez instrukcję?

(to jest ważne pytanie, odpowiedź powinna wiele wyjaśnić)

Instrukcja należy zatem do sterowania, a nie do procesu.

Zgoda to ważne.

Mam nadzieję, że widać już co się porobiło.
Proces pomylono z programem.
============================

Zbyt pośpieszny wniosek.

Spoko :) Wypracowany w toku wielu miesięcy dyskusji z na prawdę poważnymi fachowcami.

No dobrze ale czy jest pan w stanie podać przykład procesu, który nie można przedstawić w postaci algorytmu? ;-(

2. Dlaczego komputer ma zastępować człowieka w decydowaniu? NO DLACZEGO?

- ..

Takie i podobne historyjki słyszę od ok. 30 lat (zaraz zaraz ile to będzie? 28!)

Ale o nich później, bo należałoby po kolei omówić osiągnięcia oraz manowce.

Teraz tylko nadmienię, że system rezerwacji działa jedynie pod warunkiem, że klient zauważy iż data ze sprawdzania wolnych miejsc nie przenosi się do aplikacji rezerwującej. W przeciwnym razie czapa, będzie miał bilet na inną datę :D. Serio.

Co do krytyki konkretnych aplikacji to zgadzam się w 100%. Ja odnoszę się jednak do koncepcji.

Prawdziwy ekspert i tak się nie przestraszy. Bo prawdziwy ekspert w każdej chwili może się przerzucić na obszary jeszcze nie opanowane przez... itd.

(Prawdziwi kowboje ponadto nie oglądają się za siebie)

Cóż nie mam w sobie aż tyle pewności .. . :-(((

No i wiedziałem, ze mnie Pan wyciągnie na spytki. Już muszę przerwać, bo jutro jeszcze dłubanina przy interfejsach... bleee

I za to dziękuję. Mam także nadzieję, że inni też się włączą i moje słowa z początku pierwszego posta okażą się prawdziwe. :-D

Temat: Modelowanie czy rysowanie

Muszę włączyć się w tę dyskusję chociaż w minimalnym wymiarze. Zgadzam się z opinią Pana Marka, że włączenie "zdarzenia" porządkuje pojęcia modelowania organizacji. Nie od dzisiaj znaną praktyką jest przecież rozróżnienie pomiędzy pojęciem procesu oraz zdarzeń go wywołujących. Przecież żeby odpowiednio opisać organizację potrzebujemy, oprócz pojęć modelowania zdefiniowanych dla procesu, również pojęcie zdarzenia, które ten proces inicjują. W takiej sytuacji otrzymujemy narzędzia opisu kontektu binzesowego procesu a nie tylko samego procesu. I tak warto pamiętać o zdarzeniach temporalnych, które uruchamiają proces w określonym momencie czasu, czy zdarzeniach sterowanych przepływem lub zdarzeniach o charakterze losowym. Każde ze zdarzeń musi być odpowiednio obsłużone przez proces. Na zdarzenie możemy patrzeć jak na wyzwalacz, który uruchamia ciąg czynności, których wykonanie pozwala zrealizować określony cel procesu. Tak, w dużym uproszczeniu i zawężeniu do pojęcia zdarzenia wygląda mój sposób postrzegania pojęć modelowania organizacji...
Pozdrawiam!

Temat: Modelowanie czy rysowanie

Witam na moment :)

No i widzi Pan, sam Pan ześlizguje się na programowanie, a nie na modelowanie procesu - obsługa przerwań, algorytm,... :). To wszystko oczywiście może i powinno być klarowne i zrozumiałe, przejrzyste itd. Jak każdy dobrze napisany PROGRAM.

Kurt Lewin oprócz tego wynalazł Zarządzanie Zmianą! Bardzo dobrze sprawdzona metodologia odmrażania dużych organizacji. Termin został zagarnięty przez tych tam prawem kaduka. Niszcząc terminologię niszczy się dorobek ludzkości.

Ma Pan całkowitą rację podkreślając znaczenie procesów asynchronicznych (w normalnym języku - równoległych). Jeśli poczta czeka na przeczytanie, to modeluje się to BUFOREM (taki magazyn przejściowy, jest wiele rodzajów buforów). Jeśli dodatkowo potrzebne jest potwierdzenie dla nadawcy, że list doszedł, to wysyła się SYGNAŁ, który oczywiście należy do warstwy sterowania, a nie przetwarzania, podobnie jak kanban, andon, czy hałas gdy coś się sp... w transporcie.

Jeszcze dodam, ze przez kilka dziesięcioleci praktycy pracowali nad "czyszczeniem" definicji procesu, aby wyciągnąć do niej z niego czystą i tylko najbardziej użyteczną abstrakcję.
Aż przyszli Ci tam,... i pododawali "sobie" różności, bo przecież w programowaniu można "sobie" powprowadzać dowolną ilość zmiennych...
Zaśmiecili i teraz nie widzą gdzie się zaczyna a gdzie kończy sterowanie procesem, czyli ZARZĄDZANIE.

Instrukcja przeciwpożarowa daje wytyczne dla pewnego ciągu czynności, który NIE JEST procesem, ponieważ niczego nie przetwarza. Nie każdy ciąg czynności to proces. Przykładów jest multum...

Z deszczem chodziło mi o co innego. Obsługa takiego zdarzenia oczywiście może być potrzebna, tyle tylko, że jest ona ciągiem czynności nie przetwarzających niczego, wręcz przeszkadza procesowi. Patrz akapit poprzedni.

No i jeśli się to wmontuje w proces, to w opisie procesu znajdą się wszelakie zakłócenia procesu. WEWNĄTRZ procesu, a nie na zewnątrz. Prowadzi to do kardynalnego błędu sterowania: proces zakłócony uważamy wtedy za jedną z wersji procesu (Ci nazywają to instancją), a nie za proces z błędem. Zapisujemy i w ten sposób komputeryzujemy bałagan, zamiast stabilizować proces, Czyli USUWAĆ przyczyny zakłóceń.

Z tą rezerwacją to nie taka prosta opowiastka. Są dość zasadnicze przyczyny, dla których ta data nie jest przenoszona.

Przy tej okazji coś o wspomnianym przez Pana przetwarzaniu rozproszonym. Napisałem zbyt skrótowo o "jednym miejscu" rejestracji zasobów. Nie wiem jak to konkretnie nazwać ponieważ nie znam się na informatyce. Ale nawet największy klaster czy krata maszyn nie usuwa przyczyn, dla których wszystkie usługi aplikacji są (nie fizycznie przecież) pod jedną tzw. domeną.

[Edycja] W tzw. międzyczasie dołączył Pan Jakieła, więc na gorąco. Oczywiście ma Pan rację, że każdy proces jest w jakiś sposób inicjowany. W tej starożytnej notacji opis tego momentu robiło się przy pomocy tzw. kryterium startu. Na przykład "nie reaguj na 2 przekroczenia poziomu krytycznego, jeśli czas pomiędzy nimi jest dłuższy, niż 200 sekund, a jeśli jest krótszy to startuj". Zatem kryterium, porównanie, decyzja - STEROWANIE.
Albo "porównaj datę serwera z datą niezależnego kalendarza. Jeśli ta pierwsza jest większa, startuj".

Super, ze Pan dołączył :)Andrzej Góralczyk edytował(a) ten post dnia 14.10.07 o godzinie 14:25

Temat: Modelowanie czy rysowanie

Hmmm. Modelowanie procesów postrzegam jako przygotowanie projektu:
1. aplikacji,
2. wdrożenia jakiejś metody zarządzania, np: ISO 9001.
Jeżeli modelujemy bez intencji tworzenia oprogramowania to wystarczy jak pozostaniemy przy rysowaniu, pisaniu procedur oraz instrukcji. Niestety lub stety tak się składa jednak, że bez komputera dzisiaj ani rusz więc i metodologia zarządzania o jakąś aplikację się otrze. Przypadek nie zadawania się z oprogramowaniem nie wymaga zgłębiania szczegółów. Rozumiem jednak, że rozmawiamy o ciągu dalszym także z komputerem, czyli detali moodelowania nie pomijamy.

Tym samym ześlizgiwanie się na programowanie w modelowaniu jest dla mnie próbą znalezienia wspólnego języka pomiędzy teorią i praktyką, która bez IT dzisiaj nie istnieje. Jeżeli ograniczyć się do procesów biznesowych to tendencja informatyzacji całości jest nie do powstrzymania. Zreszą nie widzę w tym nic zdrożnego (głupków, oszołomów oczywiście pomijam w rozważaniach).

Zakładam więc tym samym, że najważniejszym efektem końcowym modelowania będzie znalezienie drogi właściwego opisania procesów biznesowych:
- albo celem wdrożenia dostępnych aplikacji,
- albo celem stworzenia nowej aplikacji.

Aby tak się stało praktycy biznesu muszą porozumieć się z praktykami IT. Jeżeli więc zauważyć, że pozyskanie wiedzy jest jednym z najtrudniejszych problemów do rozwiązania, to zrozumiałym jest dla mnie niedoskonałość dzisiejszych metod notacji. To że jesteśmy na początkowym etapie tegoż jest dla mnie oczywistą oczywistością. ;-D

Powyższego nie zmienia fakt już wieloletniej historii zmagania się z problemem. Ostatnie lata rozwoju informatyki pokazują jednak, że rozwój metodologii nie był priorytetem. Priorytetem były i są rozrywka, multimedia, wygląd GUI, .. . Przyczyniają się one oczywiście do postępu IT ale w dziedzinie o której dyskutujemy to wg mnie nie za bardzo.

Cóż więc mamy do dyspozycji? Mamy reguły (wnioskowania, sterowania, akcji), scenariusze, ramy, obiekty no i omawiane modelowanie z wykorzystaniem nowych języków. Proszę uzupełnić jeżeli coś pominąłem.

Fakt niedoskonałości powyższego jest niepodważalny. Ale niedoskonałość tą nie traktuję jako argument do negacji prezentowanego podejścia. Całą Pańską krytykę traktuję jako konstruktywne poszukiwanie lepszych rozwiązań. Chętnie zapoznam się z innymi propozycjami.

No i na koniec jeżeli oderwiemy się od biznesu i zaczniemy rozważać modelowanie systemów z bazą wiedzy z jakiejś dziedziny, choćby tak ważnych jak medycyna, chemia to poprzeczkę w zakresie pozyskiwania wiedzy i jej właściwej reprezentacji podnosimy wyżej.

Potrzeba niezwykłego rozumu aby zrozumieć rzeczy najprostsze.

Temat: Modelowanie czy rysowanie

No właśnie mnóstwo czasu poświęcam prostowaniu. Po to kłócę się z różnymi "guru", przekładam schematy BPML na język procesów, toczę od wielu miesięcy dyskusje z Arturem Kasprzykiem (taki modelarz, tyle że bardzo dobry i przy tym uczciwy).

Teraz też mam spiętrzenie w robocie bo jadę na konferencję w góry, gdzie będę informatykom ładował wykład oraz 2 warsztaty o organizacji projektowania software'u i o modelowaniu procesów. To jest ciężka orka, ale coraz więcej osób rozumie, co usiłuję tłumaczyć (niestety na swój sposób, zapewne nie zawsze zrozumiały).

Ale najbardziej wqrwiam się na te komitety normalizacyjne, które grzebią w procesach BEZ udziału specjalistów od procesów, podobnie jak w ontologiach bez udziału filozofów czy w e-learningu bez udziału pedagogów. Wyważają otwarte drzwi, a jak nie wyważą to walą kardynalne błędy.

Temat: Modelowanie czy rysowanie

Andrzej G.:
No właśnie mnóstwo czasu poświęcam prostowaniu. Po to kłócę się z różnymi "guru", przekładam schematy BPML na język procesów, toczę od wielu miesięcy dyskusje z Arturem Kasprzykiem (taki modelarz, tyle że bardzo dobry i przy tym uczciwy).

Teraz też mam spiętrzenie w robocie bo jadę na konferencję w góry,

Szczyrk?

gdzie będę informatykom ładował wykład oraz 2 warsztaty o organizacji projektowania software'u i o modelowaniu procesów. To jest ciężka orka, ale coraz więcej osób rozumie, co usiłuję tłumaczyć (niestety na swój sposób, zapewne nie zawsze zrozumiały).

Powodzenia i dziękuję za indywidualne konsultacje. :-D

Ale najbardziej wqrwiam się na te komitety normalizacyjne, które grzebią w procesach BEZ udziału specjalistów od procesów, podobnie jak w ontologiach bez udziału filozofów czy w e-learningu bez udziału pedagogów. Wyważają otwarte drzwi, a jak nie wyważą to walą kardynalne błędy.

Niestety to prawda. :-((( Ale chociaż my możemy się "posprzeczać". :-D

Temat: Modelowanie czy rysowanie

Nie Szczyrk. Kościelisko, doroczna konferencja użytkowników Oracle (PLOUG org)

A Szczyrk w tym roku w Wiśle jest chyba...Andrzej Góralczyk edytował(a) ten post dnia 14.10.07 o godzinie 22:44

Temat: Modelowanie czy rysowanie

Andrzej G.:
Problem w tym, że temat poważny, więc trzeba mocno przysiąść aby przeanalizować co było napisane i wgłębić się w temat. A ja aż tule czasu teraz nie mam.

No ale przynajmniej zasygnalizuje swoje wątpliwości.

1. BPMN łamie poprzednie standardy opisu procesów (ANSI, SIPOC) wprowadzając zdarzenia do opisu "wykonania procesu". Nawiasem mówiąc, co to jest wykonanie procesu?

Brakuje mi tu definicji procesu, powszechnie używana:

Procesem nazywamy czynność lub logicznie powiązany ciąg czynności przetwarzajacy wejscie w wyjście. Dodaje się często: proces wymaga zasobów i reguł sterujących by zaistnieć.

SIPOC: Suppliers - Input - Process - Output - Customer. Dochodzi tylko dostawca tego co na wejsciu i odbiorca tego co na wyjsciu. Dostarczenie produktu jest niczym innym jak zdarzeniem, tu zdefiniowanym "niewprost". Modelując procesy za pomocą diagramów nie ma potrzeby definiowania dostawcy i odbiorcy bo to wskazują połączenia na diagramach. Tak wiec BPMN to na swój sposób SIPOC w postaci graficznej. Inaczej rzecz biorąc SIPOC to: proces poprzedzający-zdarzeniedostawa-proces-zdarzeniedostawa-procesnastępny. Dla mnie np. w SIPOC następuje pewne pomieszanie. Jeżeli uznamy, że proces ma zasoby, w szczególności jego wykonawcę (własciciela procesu) do dostawca i klient to właściciele procesów poprzedzającego i następującego.

Stan wejscia i wyjścia zawsze można nazwac zdarzeniem lub produktem, zdarzeniem jest wystąpienie produktu. Moim zdaniem wystąpienie procesu jest instancją jego abstrakcji. Jeżeli możemy mówić o zdefiniowanym procesie przyjęcia dokumentu na dzienniku podawczym, to każdy nowy dokument generuje wystąpienie procesu, na wejsciu mamy dokument, na wyjściu dokument zarejestrowany w rejestrze (czym by on nie był).

Nie widze to kolizji z ANSI czy SIPOC poza tym, że te moim zdaniem bywaja nieprecyzyjne. W normei ISO czytamy: Proces to logiczny ciąg czynności, których celem jest dostarczenie klientowi (zewnętrznemu lub wewnętrznemu ) określonego wyrobu zgodnego z jego wymaganiami. To jakby uściciślenie definicji procesu do potrzeb zarządzania.

- Zdarzenia nie należą do procesu, nie mogą należeć, gdyż proces to przetwarzanie, a nie bieg wydarzeń! Zdarzenia mogą należeć do ontologicznego porządku sterowania procesem, ale nie do procesu.

Czym sie różni przetwarzanie od biegu wydarzeń? Proces to przetwarzanie, jak więc nazwac granice pomiedzy procesami? Co wskazuje na koniec i początek procesu? Zdarzenie to wystąpienie jakiegokolwiek stanu np. postawienia pieczątki, zmiany stanu skupienia destylowanej ropy naftowej....

- Proces - ten w fabryce albo w biurze - to nie bieg wydarzeń lecz sekwencja operacji przetwarzania (ang. processing). Proces to nie sekwencja instrukcji do wykonania (program).

A kto mówi, że proces to sekwencja instrukcji? Taką sekwencja moze być co najwyżej scenariusz lub przepływ pracy (po polsku workflow :))

Procesem bedzie opracowanie oferty, na jego wejsciu będzie np. zapytanie a na wyjściu zatwierdzona oferta. Pojawienie się zapytania i zatwierdzenie oferty do wysłania to zdarzenia. Sekwencją czynności będzie ich lista z wariantami opisjaca sposób opracowania i zatwierdzenia tej oferty. Ale to już nie proces tylko przepływ pracy, procedura czy jak to tam nazwać. Można to pozostawić w gestii sprzedawcy, można mu próbować narzucić styl pracy (programowac sprzedawcę? też w to nie wierzę).

----

Mam nadzieję, że widać już co się porobiło.

Proces pomylono z programem.

Owszem zgadzam się z powyższymi moimi uwagami :)

============================

Dlaczego albo po co pomylono? A no bo za projektowanie procesów wzięli się informatycy, wraz ze swoimi różnorakimi "guru". I oni nie projektują procesów, tak jak projektuje to zawodowiec czyli inżynier przemysłowy. Oni piszą program dla komputera i dla człowieka korzystającego z komputera.

No i dziwią się że to nie działa. Że człowiek wcale nie "wykonuje" programu, tylko robi to, co chce robić.

Tu się zgadzam w 100%, informatycy (nie tylko) mylą procesy z programowanymi łańcuchami zdarzeń.

(Wyjaśniam. Tzw workflow czyli kolejka zadań ustawiona człowiekowi do wykonania przez ten cały BPM, otóż workflow nie działa, chyba że łupnie się kary pieniężne wszystkim, którzy się nie podporządkują. Czyli dokładnie tak, jak w każdym innym najgorszym sposobie zarządzania.)

:) prawda, osobiście jestem wrogiem "modelowania" kompetencji i kwalifiakcji... ale BPM to procesy a nie przepływy pracy :)

Co gorsza, większość tych "projektów" które widziałem, to programy pełne pluskiew, jak każdy kiepski program. Niedowiarkom proponuję zajrzeć do angielskojęzycznej Wikipedii i UWAŻNE przejrzenie tych RYSUNKÓW, które można znaleźć tam i w linkach z tamtej strony. Nawet człek nie zorientowany w procesach bez trudu zauważy dowolności, niekonsekwencje itd.

Zawsze można źle zamodelować proces...

=========
2. Dlaczego komputer ma zastępować człowieka w decydowaniu? NO DLACZEGO? Zapytuję ponieważ nie widzę w tym sensu, a w zamian widzę zagrożenie syndromem Wielkiego Brata. Przeczołgałem na tę okoliczność jednego z głównych "guru" Ismaela Ghalimi, jak zwykle bez osobistej satysfakcji. No ale Ismael nie potrafił odpowiedzieć na tak podstawowe pytanie o przesłankę jednego z fundamentalnych założeń tej całej zabawy w BPMN.

BPMN nie ma nic wspolnego z programowaniem ludzi. BPMN jak każda inna notacja jest jak literki, można pisac wiersze i można recepty na życie, można i bzdury, nie obwiniał bym żadnej notacji za próby odmóżdżania ludzi.

==========

3. Z systemami też nie jest lepiej. Dlaczego na przykład "modeluje" się coś tam w postaci drzewa (patrz rysunki powyżej), a następnie udaje się, że to model organizacji albo hierarchii procesów albo czegoś tam jeszcze? A co z organizacjami o strukturze sieci (budownictwo) albo pierścienia (korporacje handlowe np. w Azji, czy dawne centra przemysłowo-rolnicze na Śląsku)?

Trzeba je o protu umieć zamodelować.

Wcale nie dlatego, że hierarchia jest właściwym modelem organizacji. Zresztą coraz mniej jest w dobie organizacji macierzowych.

Nie widziałem jeszcze żadnej czystej macieżowej organizacji w praktyce ... a w ideały wierze tylko przed snem :)

Otóż dlatego - jak przypuszczam - że informatycy natrafiają na podstawową trudność (zagadnienie identyfikatora), która zmusza ich do rejestracji wszystkich pracujących zasobów systemu informatycznego w jednym miejscu. Oczywiście przy odrobinie wyobraźni mogliby uwolnić się od tego ograniczenia w warstwach bliskich Użytkownikowi (jak ja to robię w niektórych swoich witrynach interenetowych). Ale do tego trzeba znać dobrze modelowany przedmiot, a oni nie znają, tylko biorą z sufitu (co to jest model procesowy organizacji? To obraz jak sobie organizację wyobraża projektant).

Moim zdaniem o modelu można mówić tylko wtedy gdy opisuje organizację, jeżeli nie opisuje jej jest właśnie tylko obrazkiem.

System musi mieć pętle w swojej topologii. Pętle sprzężeń. Inaczej nie jest systemem.

Nie musi mieć, może mieć, moze być system bez pętli, osobna dyskusją jest zachowanie sie takiego systemu. Nie spotkałem w teorii systemów wymogu posiadania pętli przez system. Prawdą zaś jest, że pętla sprzężenia (koniecznie ujemngo) stabilizuje system jeżeli wykazuje tendencje do niestabilnosci (a nie musi).

Oczywiście powyższe nie jest krytyką gremialną, tylko krytyką wybranych podejść jakie można zaobserwować w pracach informatyków.

Fakt :)

CU

Temat: Modelowanie czy rysowanie

Andrzej G.:
No właśnie mnóstwo czasu poświęcam prostowaniu. Po to kłócę się z różnymi "guru", przekładam schematy BPML na język procesów, toczę od wielu miesięcy dyskusje z Arturem Kasprzykiem (taki modelarz, tyle że bardzo dobry i przy tym uczciwy).

Nie rozumien, może poda Pan jakiś przykład "przekładania BPMN na język procesów?"

Może mi umknęło, jeżeli tak to bardzo przepraszam, Panie Andrzeju nie znalazłem Pana definicji procesu, na którą Pan sie powołuje? Można prosić? Pan napisze definicje procesu, którą Pan uznaje. To nam pomoże uniknąć nieporozumień...

Proszę mnie źle nie zrozumieć, nie czepiam się tylko ortodoksyjnie czasem przestrzegam posiadania definicji dyskutowanych pojęć...

Bo jeżeli sie dobrze domyślam to Pana rozumiem, jeżeli się źle domyślam to nie rozumię stąd ta prośba...

Ja definicje procesu przytoczyłem (patrz poprzedni post), teraz dodam tylko, że:

Proces wymaga reguł nim sterujacych, moga to być: procedury, scenariusze, opisy przepływu pracy, programy itp. to tylko kwestia nazwy jaką nadamy na zdefiniowaną sekwencję czynności z wariantami 9dlatego wole słowo scenariusz) ... ale może to być także reguła stanowiaca: "decyzja człowieka", zresztą moja ulubiona :)

Podam przykład: kancelaria prawna, proces wydawania opini prawnej, ma na wejsciu tekst (pojawia sie tekst do zaopiniowania, to jest zdarzenie lub tak zwany wyzwalacz), prawnik (zasób, tu także właściciel procesu) opiniuje tekst (dopisuje co o nim sądzi), po zakończeniu procesu na wyjściu pojawia się (tu kolejne zdarzenie) tekst wraz z opinią i parafą prawnika.

Nie ma moim zdaniem sensu opisywać tego jak prawnik wydaje opinię prawną, to jego kompetencje, ale faktycznie znam takich co te kompetencje usiłuja modelwoać... ale Ci właśnie rysuja obrazki a nie modelują.

Dla SIPOC należy dopisac kto tekst przyniósł i kto odbierze opinie prawną, na diagramie było by to po protu narysowane. Jednak uważam,ze SIPOC miesza pojęcia procesu i jego zasobów (połączenie dostawcy z procesem) dlatego powoduje wiele nieporozumień, między innymi dlatego, ze nie da sie z opisów SIPOC dojść kto z kim się komunikuje w procesie bez dokładnego określenia właściciela (wykonawcy) procesu. Czasem widze jak ratują się ludzie dodakowymi kolumnami w rodzaju: udziela informacji itp...

Uważam, że często myli się właśnei komunikację z procesem lub przepływem pracy. Zwykłe zasięganie opinii od kolegi jest komunikacją a nie procesem zasięgania opinii. Dlatego zbawieniem dla mnie jest w notacji takiej jak BPMN możliwość łatwego oznaczenia sytuacji komunikowania się niezależnie od łańcucha procesów (tu pojawia się pojęcie sieci, bardzo łatwe do pokazania w BPMN).

Troszke tu mi nie pasuje Pana stwierdzenie dotyczące firm budowlanych, one realizują projekty a te nie są procesami z definicji (proces jest powtarzalny, projekt unikalny).

Temat: Modelowanie czy rysowanie

Ale przecież Pan ją przytoczył, ja wcześniej też, tylko "własnymi słowami". Ciąg czynności, który pobiera coś na wejściu i przetwarza w coś na wyjściu.

Nie ma ani słowa o zdarzeniach w tej definicji.

To nie jest kwestia uznawania, czy nie uznawania. To kwestia fundamentów metodologicznych z jednej strony (nie mieszajmy modalności!), a z drugiej wielu wielu lat szlifowania najlepszych praktyk.

Z tego punktu widzenia SIPOC zawiera oczywisty błąd, ponieważ żadne podmioty nie wchodzą w definicję procesu. Na przykład na schematach Rummela-Bracha(chyba dobrze napisałem?) podmioty reprezentuje się obszarami, w których proces przebiega.

Oczywiście wszystko co "się dzieje" jest zdarzeniem, czy sekwencją zdarzeń. Ale nie mówimy o wszystkim, mówimy o procesie.

Firmy budowlane przytoczyłem jako przykład struktury organizacyjnej, a nie procesu. Ale największe oczywiście mają proces, potokowy w dodatku - projekt za projektem, w nakładających się sekwencjach :).

Nawiasem mówiąc, skąd Panu przyszło do głowy, że proces jest powtarzalny, a projekt unikalny? Może chodzi o bałaganiarski projekt?

Ten "Przekład BPML/N na język procesów" to skrót myślowy, przepraszam. W praktyce to wygląda na przykład tak, że jak modelarz chwali się co wymodelował i pokazuje obrazki, to na ogół na takim obrazku jest fragment, o którym on szczególnie nie chce mówić. No to ja mówię i pokazuję, że można było prościej, można było przeprojektować wg klasycznych metod Inżynierii Przemysłowej (niektórzy po raz pierwszy je widzą) itp. Po prostu cierpliwie robię swoją belferską robotę.Andrzej Góralczyk edytował(a) ten post dnia 15.10.07 o godzinie 11:44

Temat: Modelowanie czy rysowanie

Ciekawe jest to, co Pan mówi o systemach.

Ja się nie znam na teorii systemów, trochę wiem jak się zachowują w praktyce układy, o których mówi się "system".

Ale mówi się tam, że system to zbiór POWIĄZANYCH ze sobą elementów... itd. Czy te powiązania to nie są sprzężenia?

Napisałem "sprzężenie", obaj Panowie dodali "zwrotne". Otóż nie, w praktyce sterowania procesami mamy także sprzężenia forward. Na przykład niektóre rozwiązania sterowania wizualnego służą do tego, zwłaszcza te, które wspomagają dostosowania lokalne.

Na przykład reakcja dostosowująca na sygnał, że "następny" w procesie już czeka albo przeciwnie, ma zaległość. Zresztą najwięcej takich rzeczy spotyka się w zastosowaniach wiedzy o dynamicznych systemach otwartych (por. słynny przed laty Insurance World).Andrzej Góralczyk edytował(a) ten post dnia 15.10.07 o godzinie 11:59

Temat: Modelowanie czy rysowanie

Andrzej G.:
Z tego punktu widzenia SIPOC zawiera oczywisty błąd, ponieważ żadne podmioty nie wchodzą w definicję procesu. Na przykład na schematach Rummela-Bracha(chyba dobrze napisałem?) podmioty reprezentuje się obszarami, w których proces przebiega.

Rummlera-Brache'a, owszem obszary (powszechnie zwane basenami i torami) dotyczą tam ról (właścicieli procesu/czynności).

Oczywiście wszystko co "się dzieje" jest zdarzeniem, czy sekwencją zdarzeń. Ale nie mówimy o wszystkim, mówimy o procesie.

Zdarzenie lub tryger w nomenklaturze notacji (nie tylko BPMN) to każdy rejestrowalny fakt: pojawienie sie dokumentu, zmniejszenie stanu magazynowego poniżej założónego minimum...itp. Proces zaopatrzeniowy "staruje" nie z powietrza a w wyniku jakiegoś zdarzenia np. pojawienie się zamówienia.

Firmy budowlane przytoczyłem jako przykład struktury organizacyjnej, a nie procesu. Ale największe oczywiście mają proces, potokowy w dodatku - projekt za projektem, w nakładających się sekwencjach :).

Sekwencja projektów to program. Program można już nazwać procesem.

Nawiasem mówiąc, skąd Panu przyszło do głowy, że proces jest powtarzalny, a projekt unikalny? Może chodzi o bałaganiarski projekt?

Z definicji tych pojęć. Obie, i PMI i Prince2 definiują projekt jako unikalny. Każdy projekt ma swój osobny budżet, kierownika, zakres i harmonogra, zdefiiowany proces ma te wielkosci zawsze stałe i jest powtarzalny. W firmie budowlanej (u developera) procesem jest np. projektowanie budynków, ich realziacja to osobne projekty.

Ten "Przekład BPML/N na język procesów" to skrót myślowy, przepraszam. W praktyce to wygląda na przykład tak, że jak modelarz chwali się co wymodelował i pokazuje obrazki, to na ogół na takim obrazku jest fragment, o którym on szczególnie nie chce mówić. No to ja mówię i pokazuję, że można było prościej, można było przeprojektować wg klasycznych metod Inżynierii Przemysłowej (niektórzy po raz pierwszy je widzą) itp. Po prostu cierpliwie robię swoją belferską robotę.

Pan tu napisał o złych modelach a my rozmawiamy o teorii czyli dobrych modelach. Tez uważam, że pojawienie się na modelu "dziwnych symboli" to próba ukrycia niezrozumienia opisywanego obszaru.

Temat: Modelowanie czy rysowanie

Andrzej G.:
Ciekawe jest to, co Pan mówi o systemach.

Ja się nie znam na teorii systemów, trochę wiem jak się zachowują w praktyce układy, o których mówi się "system".

Dlatego ja wole posługiwac się pojęciem "system" gdzieś zdefiniowany, np. w ogółnej teorii systemów :)

Ale mówi się tam, że system to zbiór POWIĄZANYCH ze sobą elementów... itd. Czy te powiązania to nie są sprzężenia?

Powiązanie można nazwać sprzężeniem, jednak należy okreśłić czy to sprzężenie czy sprzężenie zwrotne... połączenie transportu w wyładunkiem można nazwać sprzężeniem tych procesów, jednak sprzężeniem zwrotnym (stabilizujacym te parę) będzie połączenie zwrotne czyli np. połączenie wyładunku do początku procesu transportu: transport się nie zacznie do czasu zakończenia wyładunku co np. chroni przed kolejką do wyładowania.

Napisałem "sprzężenie", obaj Panowie dodali "zwrotne". Otóż nie, w praktyce sterowania procesami mamy także sprzężenia forward. Na przykład niektóre rozwiązania sterowania wizualnego służą do tego, zwłaszcza te, które wspomagają dostosowania lokalne.

Na przykład reakcja dostosowująca na sygnał, że "następny" w procesie już czeka albo przeciwnie, ma zaległość. Zresztą najwięcej takich rzeczy spotyka się w zastosowaniach wiedzy o dynamicznych systemach otwartych (por. słynny przed laty Insurance World).

Pan opisał sprzężenie zwrotne, sprzężenie forward to sytuacja w której inicjator transportu wysyła "zawczasu" do procesu wyładunku informacje o wielkości dostawy np. w celu kontroli lub przygotowania odbiorcy do odebrania ładunku.

Temat: Modelowanie czy rysowanie

Andrzej G.:
Ciekawe jest to, co Pan mówi o systemach.

Ja się nie znam na teorii systemów, trochę wiem jak się zachowują w praktyce układy, o których mówi się "system".

Ponieważ nie istnieje jedna jednolita i ogólnie uznana teoria systemów, to właściwie nie ma powodów aby aż tak bardzo krytycznie oceniał Pan siebie.

Ale mówi się tam, że system to zbiór POWIĄZANYCH ze sobą elementów... itd. Czy te powiązania to nie są sprzężenia?

Dla mnie nie. Powiązanie to łącznik elementów systemu. Sprzężenie to łącznik wyjścia z wejściem systemu. Stąd każde sprzężenie jest połączeniem ale nie każde połączenie jest sprzężeniem. Dlatego też sprzężenia dla mnie są zwrotne. Sprzężenia mogą być ujemne oraz dodatnie.

Domyślnie sprzężenie zwrotne jest sprzężeniem ujemnym ponieważ tylko takie gwarantuje trwałość systemu. Gwarantem jest przeciwny znak sprzężenia. Np. załadunek samochodu: załaduj paczkę, jak jest miejsce ładuj następną paczkę, jak nie ma miejsca zakończ załadunek.

Dodatnie sprzężenie zwrotne to sposób na narastanie odchylenia. Jeżeli nie zadziałają żadne zabezpieczenia to dodatne sprzężenie doprowadza do samounicestwienia systemu. Łatwym do zrozumienia przykładem może być czajnik elektryczny. Włączenie prądu powoduje wzrost temperatury grzałki. Jeżeli nie wyłączymy go jednak w odpowiednim momencie (ujemne przężenie zwrotne) to grzałka się przepali.

Napisałem "sprzężenie", obaj Panowie dodali "zwrotne". Otóż nie, w praktyce sterowania procesami mamy także sprzężenia forward. Na przykład niektóre rozwiązania sterowania wizualnego służą do tego, zwłaszcza te, które wspomagają dostosowania lokalne.

Sprzężenie forward to powiązanie (interfejs?). Może być także ekstrapolacją, która przekazuje wyniki dotychczasowych działań z jednego systemu (modelu) do drugiego. Np: zakończono załadunek, więc teraz proszę dostarczyć do klienta.

Na przykład reakcja dostosowująca na sygnał, że "następny" w procesie już czeka albo przeciwnie, ma zaległość.

To przykład ujemnego sprzężenia zwrotnego.

Oczywiście nic nie stoi na przeszkodzie aby sprzężenie nazywać łącznikiem ale 1) należy to bardzo wyraźnie zdefiniować, 2) jak dla mnie może być przyczyną nieporozumień. Osobiście nie podoba mi się nazwanie sprzężeniem połączenia transportu w wyładunkiem. Czemu nie nazwać tego tak jak w mówimy naturalnym języku: połączeniem procesów?

No i ciągle tak jak dotychczas krytyka dotyczy konkretnych błędów modelarzy a nie modelowania. Uff, chyba dres i Pan Jarek pomógł. ;-D

Temat: Modelowanie czy rysowanie

No i Pan Jacek, też oczywiście wsparł. Panie Jacku, a nie brakuje tutaj jeszcze pojęcia interfejsu - sprzęgu, bramy, portu jak to drzewiej wołano? A to, że arogancja środowiska IT w stosunku do innych środowisk jest za duża to Pan Andrzej już udowodnił. ..