Temat: Naiwne modelowanie procesów
Jarek Żeliński:
Artur Kasprzyk:
"Modelowanie to sztuka a nie nauka ścisła (D.Faulkner, Strategie Konkurencji). "
Modelowanie, to nauka/wiedza/umiejętność. Odwoływanie się do sztuki, w moim przekonaniu jest albo próbą podbudowania swojego ego, albo rozmyciem odpowiedzialności w przypadku, gdy odbiorca modelu żąda konkretów.
Cóż, każdemu wolno głosić także tezę, że obowiązkowy egzamin z rysunku odręcznego (sztuka czy nauka?) na wydział Architektury Politechniki Warszawskiej jest „próbą podbudowania swojego (czyjego?) ego, albo rozmyciem odpowiedzialności w przypadku, gdy odbiorca modelu żąda konkretów”.
[...]
Pozwolę sobie sprowadzić dyskusję ponownie na grunt modelowania organizacji (o tym jest Pański artykuł, nieprawdaż?). W przypadku modelu organizacji, skonstruowanie go jest typowym inżynierskim działaniem mającym, moim zdaniem, ze sztuką o tyle coś wspólnego, że sztuką jest go zrobić (gdyz wymaga długiego procesu edykacyjnego oraz etapu nabierania doświadczenia). W przeciwieństwie do Sztuki, nie oceniamy jego subiektywnego piękna, lecz obiektywną uzyteczność.
Dla mnie to nie przypadek, że inwestor chce ze zrozumieniem uczestniczyć w całym procesie powstawania inwestycji. Architekt powinien więc umieć narysować i zaprojektować to co potem matematycznie po inżyniersku opracuje.
Uczestniczenie ze zrozumieniem nie oznacza konieczności rozumienia symboli użytych w modelu (bez względu na to, czy jest to BPMN, czy UML...za symbolami stoi całkiem złożona semantyka, a same rysunki prezentują jedynie część informacji znajdujących się w modelu). Analityk jest od tego, by model interpetować.
Na GL (i nie tylko) są ludzie negujący istnienie talentu czy nawet predyspozycji, ich poglądy to np. NLP. [...]
Co z tego wynika w kontekście dyskusji ?
Pozwolę sobie także podważyć kolejną tezę:
"A gdzie semiotyka? Patrząc na model (diagram) zastanów się czy rozumiesz (bez specjalistycznego szkolenia) użyte symbole bez zaglądania w ich słownik. Im bardziej użyte symbole są dla Ciebie niezrozumiałe tym gorszy to model bo ktoś nie zadbał o jego semiotykę, czyli o to by był dla Ciebie (Ty, a nie jego autor, jesteś adresatem modelu!) zrozumiały a przynajmniej stosunkowo łatwy w percepcji."
Model nie jest dla odbiorcy docelowego, lecz analityka.
W moich projektach model jest kluczową, testowaną z zamawiającym hipotezą, że ja jako analityk zrozumiałem organizacje (tu kłania się ogólna teopria systemów i analiza systemowa), zamawiający MUSI mi te hipotezę potwierdzić bo ona
JEGO opisuje.
Oczywiście, że musi zatwierdzić. Ale, mam nadzieję, nie zostawia Pan Klienta sam na sam z modelem, tylko służy Pan pomocą w interpretacji zapisów.
Tak jak schemat ideowy telewizora jest dla projektanta i serwistanta, projekt budowlany jest dla architekta i ekipy budowlanej.
ale i telewizor i projekt architektoniczny zatwierdza jego nabywca na bazie tego co zobaczy (wizualizacja, projekt). Zwracam uwagę, że napisałem to o modelu procesow (czyli o tym co opisuje zamawiajacego) a nie o modelach UML przyszłego oprogramowania.
W poprzednim akapicie odniosłem się do zatwierdzania model (przez cały czas pamiętając, że rozmawiamy o modelu organizacji).
Wyniki modelowania (wnioski z projektu) są dla odbiorcy końcowego. O semiotykę powinno się więc pytać analityków, a nie odbiorców.
Owszem ale należy ją, semiotykę, znać i stosować. Moim zdaniem np. psycholog musi wiedziec co to jest psychoanaliza a nie jego pacjent ale psycholog powinien ją umieć świadomie stosować w stosunku do pacjenta, sam pacjent nie musi się znać na psychoanalizie ale musi rozumieć o co pyta psychoanalityk.
Oczywiście, że nalezy ją znać. Ale przecież nie rozmawiamy o sytuacji, w której analityk wykorzystuje język, którego nie zna..bo o czym tu rozmawiać.
Na koniec "Jeżeli jesteś menedżerem i interesuje Cię analiza jako produkt za który płacisz, spokojnie możesz przejść do ostatniego akapitu a dowiesz się jak nie płacić za buble czyli „naiwne modele procesów i organizacji”.
Przechodzę. I czytam. "Moim studentom i kursantom powtarzam: dobry model jest jak wiersz, trzeba być poetą by go napisać ale do przeczytania powinna wystarczyć znajomość alfabetu." Proszę o podpowiedź - jak mam nie płacić ?
Moi klienci mogą zgłaszać zastrzezenia do moich diagramów (diagramy opisujące procesy w ich orgazniacjach stanowią część dokumentacji za którą płacą). Zastrzeżenia zgłaszają na podstawie tego co "wyczytają" z tych diagramów. Gdyby była tam nieprawda to kazali by poprawić lub nie zaplacili by. Osobiście najbardziej boję się projektów, w ktorych zamawiający zatwierdza dokumenty nie rozumiejąc ich treści. Co prawda niejden wykonawca może (i robi to!) powołać sie na tak zatwierdzony dokument wpychając bubla klientowi ale nie ma to wiele wspólnego z etyką.
Wydaje mi się, że nieetyczne zachowania nalezy pominąć w dyskusji, gdyż jest to osobny temat. Aczkolwiek w dalszym ciągu będę podkreślał, że model utworzony z wykorzystaniem specjalizowanego języka jest dla analityka, a Klient zatwierdza więdzę w nim zapisaną, której najprawdopodobniej bez pomocy analityka sam z modelu nie wyczyta.
Powracając do zacytowanego fragmentu Ciekaw jestem czy inni także mają takie wrażenia po obejrzeniu niektórych modeli.
Jakich modeli ?
cały czas pisze o "modelach procesów i organizacji".
Miałem na myśli cechy "modelu procesów i organizacji", które kwalifikują model jako "naiwny".
Jeśli model jest niezgodny z celem przedsięwzięcia, to nie ma o czym dyskutować.
Moim zdaniem model z definicji musi opisywać rzeczywistość a nie "być zgodnym z celem przedsięwzięcia".
"Jako taką", czy zgodną ze specyfiką (celem) przedsięwzięcia ?
"Podstawą w modelowaniu procesów biznesowych jest ich pragmatyka czyli określenie co w kontekście organizacji oznaczają pojęcia słownikowe i reguły gramatyczne (semantyka i syntaktyka). Bardzo ważne jest by elementy słownika (użyte symbole) , także w języku (systemie komunikacji) adresata modelu oznaczały to samo lub miały co najmniej podobne znaczenia (jest to tak zwana semiotyka języka graficznego, znaków)."
Co mówi pierwsze zdanie: "Podstawą w modelowaniu procesów biznesowych jest ich pragmatyka czyli określenie co w kontekście organizacji oznaczają pojęcia słownikowe i reguły gramatyczne (semantyka i syntaktyka). " Mozna odpowiedzieć...oznaczają to, co mówi specyfikacja języka modelowania, ni mniej, ni więcej.
Czyli pytanie retoryczne.
Nie, bo obiekt Data w BPMN, zeleznie od tego co i po co modelujemy, może oznaczać: ekran (formatkę) wprowadzania danych, papierowy dokument z jego treścią, plik na dysku, ...
Od tego są kategorie w BPMN, czy Stereotypy w UML, by dodatkową semnatykę wprowadzić do języka. Wóczas w dalszym ciągu interpretujemy "literalnie" zapisy.
nawet treść przekazaną słownie.... i to należe zdefiniować (to jest własnie pragmatyka zastosowania języka).
Poprosiłbym o wyjaśnienie.
Drugie zdanie akapitu "Bardzo ważne jest by elementy słownika (użyte symbole) , także w języku (systemie komunikacji) adresata modelu oznaczały to samo lub miały co najmniej podobne znaczenia (jest to tak zwana semiotyka języka graficznego, znaków)". Bardzo proszę o wskazanie " języka adresata modelu" z którym np. symbol Conditional Intermediate Event z języka BPMN jest zbieżny.
Ogólnie zdarzenie (kółeczka na diagramach BPMN) ja definiuje w dokumentacji jako: "zapis faktu o którym chcemy posiadać wiedzę" więc na modelu biura podawczego nie zaznaczam kółka z opisem "Piorun podczas burzy" ale zrobię na modelu związanym z rejestracja zmian pogodowych dla placówki meteorologicznej (tu także dodatkowo pragmatyka). To gdzie to kółeczko umieszczę zależy od tego co chce pokaząc (np. warunkowe wyjście z procesu z powodu burzy). W rozmowach z klientem nie używam jednak pojęć typu "Conditional Intermediate Event" bo zachował bym się jak kiepski lekarz, który próbuje pacjentowi wytłumaczyć źródło bólu brzucha posługując terminami wyuczonymi na studiach a nie zrozumiałymi dla normanych ludzi. I to jest własnie semiotyka czyli nauka o tym co i dla kogo znacza jakiś znak (słowo to także znak mający znaczenie).
Mam wrażenie, że napisał Pan kilka zdań, ale nie odpowiedział na zadane pytanie.
Uogólniając: po ukończeniu studiów (nie tylko MBA) menedżerowie prostokąty kojarzą z procesami i czynnościami, wielu z nich łatwo uznaje kółka za zdarzenia i karteczki z zagiętymi rogami za dokumenty (dlatego moi klienci a nie ja, lubią BPMN).
A dysponuje Pan badaniami potwierdzającymi Pana tezę ? Mam bowiem wrażenie, że "po ukończeniu studiów (nie tylko MBA)" prostokąt może się menedżerowi kojarzyć z bardzi wieloma rzeczami...i szczerze mówiąc, nie wiem, dlaczego miałby się akuratnie kojarzyć z procesem. A kółko, ze zdarzeniem może zacząć kojarzyć zapewne równie szybko, jak strzałkę, kwadrat, czy cokolwiek innego, co zostanie przedstwione jako symbol reprezentujący zdarzenie.
Mam wrażenie, że języki modelowania zawierają piktogramy, które powinny się analitykowi z czymś sensownym kojarzyć, ale nie mają one nic wspólnego z językiem naturalnym odbiorcy modelu.
Ja mam inne wrażenie...
Pogubiwszy się w tezie artykułu...poproszę o pomoc.
bardziej już nie potrafie pomóc...
A gdybym poprosił o jednozdaniową tezę...
W każdym razie bawi mnie jak słyszę od autorów diagramów "tak mnie nauczono na kursie modelowania" jak słyszą jakikolwiek zarzut czy nawet proste pytanie o to co i dlaczego akurat tak narysowali bo nikt z czytających nie zrozumiał.
A co Pana konkretnie w tym bawi ?
Pozdrawiam, Artur Kasprzyk
пропозиції роботи
