Temat: tzw. obiegi dokumentów, pracy, ... itd

Witam !
Myslę, że jednym z najważniejszych wątków modelowania jest modelowanie tzw. "obiegów" z różnymi dopowiedzeniami - obiegów pracy, dokumentów, zadań, spraw, ...
Istnieją różne "konstruktory" pozwalające na graficzno-tekstowe definiowanie takich obiegów.
Taka definicja trafia do silnika obiegu i ...

... nurtują mnie następujące pytania, które chciałbym postawić uczestnikom forum:

1. Jakich najtrudniejszych konstruktorów obiego-twórczych musieli Państwo używać W PRAKTYCE ?
2. Czy możecie podać przykład (schemat) obiegu o najtrudniejszych - ale jeszcze praktycznie występujących - zależnościach pomiędzy podprocesami (lub/i zdarzeniami, itp) ?
3. Czy zdarzyło się, że jakiś gotowy system obiegu (oczywiście bez nazw własnych !) nie spełnił oczekiwań, gdyż różnego rodzaju zależności (właśnie - jakie ?) pomiędzy faktycznymi procesami u klienta były zbyt trudne do wymodelowania w tym systemie ?

Będę wdzięczny za nadesłane uwagi.
Pozdrawiam, Zdzisław Habasiński

Temat: tzw. obiegi dokumentów, pracy, ... itd

Zdzisław Habasiński:
Witam !
Myslę, że jednym z najważniejszych wątków modelowania jest modelowanie tzw. "obiegów" z różnymi dopowiedzeniami - obiegów pracy, dokumentów, zadań, spraw, ...
Istnieją różne "konstruktory" pozwalające na graficzno-tekstowe definiowanie takich obiegów.
Taka definicja trafia do silnika obiegu i ...

... nurtują mnie następujące pytania, które chciałbym postawić uczestnikom forum:

1. Jakich najtrudniejszych konstruktorów obiego-twórczych musieli Państwo używać W PRAKTYCE ?

Co to jest ten konstruktor...

2. Czy możecie podać przykład (schemat) obiegu o najtrudniejszych - ale jeszcze praktycznie występujących - zależnościach pomiędzy podprocesami (lub/i zdarzeniami, itp) ?

Jeżeli jakiś obieg dokumentu jest rudny do zamodelowania to należy się zastanowić czy na parwdę dobrze rozumiemy cel procesu

3. Czy zdarzyło się, że jakiś gotowy system obiegu (oczywiście bez nazw własnych !) nie spełnił oczekiwań, gdyż różnego rodzaju zależności (właśnie - jakie ?) pomiędzy faktycznymi procesami u klienta były zbyt trudne do wymodelowania w tym systemie ?

Tak i to nie raz: próbowano zalgorytmizować pracę ludzi a to jest nie możliwe.

Będę wdzięczny za nadesłane uwagi.
Pozdrawiam, Zdzisław Habasiński

Hm.. odpowiem też troszkę zbiorczo ;):

Po kilku latach modelowania przeróżnych firm i organizacji uważam, że:

1. nie da sie i nie ma sensu próba modelowania ludzkich kompetencji, jeżeli w zakresie obowiązków ktoś ma, że musi umieć kopiować dyskietki to nie modelujemy wnętrza procesu kopiowania dyskietek tylko przy procesie piszemy, że odpowiada za niego "kopiowacz dyskietek o oczekiwanych kompetencjach".

2. jeżeli coś jest opisane jakąś instrukcją obsługi patrz powyżej.

3. kluczem definicji każdego procesu jest odkrycie jego prawdziwego celu a nie tego w jaki sposób jest wykonywany, np. celem procesu poprawiania błędów w tłumaczeniach książek nie jest poprawianie błędów tylko jest poprawa jakości tych tłumaczeń, poprawianie błędów jest jednym ze środków osiągnięcia tego celu.

4. nie wolno pomylić procesu z jego scenariuszem (procedurą, opisem tego w jaki sposób proces jest realizowany), to prowadzi często do zupełnego pomieszania poziomów szczegółowości modeli i w efekcie braku ich przydatności.

Wdrożenie systemu obiegu dokumentów powinno mieć określony cel biznesowy, bez tego nie znany jest kontekst projektu i nie wiadomo tak na prawdę na czym się skupić i co tak na prawdę modelować.

Czym innym jest wdrożenie workflow w celu skrócenia przetwarzania faktur przychodzących a czym innym w celu nadzoru nad efektywnością tworzenia ofert w odpowiedzi na zapytania ofertowe. W pierwszym przypadku zależy nam na skróceniu czasu procesu a w drugim często na tym by oferty były odsyłane w obiecanym terminie (bo nie zawsze oferta odesłana szybko jest dobrą ofertą), nie ginęły zapytania itp.

Każdy projekt jest inny, należy go dobrze zbadac i zrozumieć.

Temat: tzw. obiegi dokumentów, pracy, ... itd

Witam !
Dziękuję za Pana uwagi. Chciałbym też dorzucić swoje 3 grosze.

co to jest ten konstruktor...

Przepraszam, ale faktycznie to nie wiem czy jest jakiś ładny polski rzeczownik na zbiorcze określenie takich rzeczy jak
"multi-merge, parallel split, synchronization, gateway...".
Właśnie te elementy obiegów miałem na myśli.

Jeżeli jakiś obieg dokumentu jest rudny do zamodelowania to
należy się zastanowić czy naprawdę dobrze rozumiemy cel procesu

Zgoda. Ale jeśli zastanowimy się, cel rozumiemy, a rzeczywistość będzie faktycznie skomplikowana ?

>> 3. Czy zdarzyło się, że jakiś gotowy system obiegu (oczywiście >> bez nazw własnych !) nie spełnił oczekiwań, gdyż różnego
>> rodzaju zależności (właśnie - jakie ?) pomiędzy faktycznymi
>> procesami u klienta były zbyt trudne do wymodelowania w tym
>> systemie ?

Tak i to nie raz: próbowano zalgorytmizować pracę ludzi a to
jest nie możliwe.

Co do możliwości zalgorytmizowania zgadzam się całkowicie.
Modelowanie obiegu przez system musi zatrzymać się na odpowiednio wysokim poziomie "abstrakcji" (przykład z kopiowaniem dyskietki zabawny ale b. wymowny !).
Jednak nie takie, przesadnie drobiazgowe, próby miałem na myśli.
Czy jednak owe Pana "nie raz" oznacza, że za każdym razem była to niezdrowa próba absurdalnej algorytmizacji, np. owego kopiowania dyskietek ?
Wydaje mi się, że jednak niektóre problemy są obiektywnie trudniejsze niż inne i stworzenie dla nich modelu (myślę nadal o tzw "obiegach") może napotkać na prawdziwe problemy a nie te stworzone przez drobiazgowość.

Wdrożenie systemu obiegu dokumentów powinno mieć określony cel
biznesowy, bez tego nie znany jest kontekst projektu i nie
wiadomo tak na prawdę na czym się skupić i co tak na prawdę
modelować.

Pełna zgoda :-)

Ośmielam się jednak ponowić prośbę o choćby jeden lub (lepiej dwa) przykłady prawdziwych problemów jakie wystąpiły w modelowaniu obiegów (choć pewnie tych stworzonych przez niwełaściwie dobraną perspektywę jest znacznie więcej).
Pozdrawiam, Zdzisław Habasiński

Temat: tzw. obiegi dokumentów, pracy, ... itd

Zdzisław Habasiński:

co to jest ten konstruktor...

Przepraszam, ale faktycznie to nie wiem czy jest jakiś ładny polski rzeczownik na zbiorcze określenie takich rzeczy jak
"multi-merge, parallel split, synchronization, gateway...".
Właśnie te elementy obiegów miałem na myśli.

To sie nazywa "semantyka notacji": skonczona lista dozwolonych symboli i opis ich znaczeń na diagramie, inaczej rzecz nazywając: słownik symboli. Poprawna notacja (konstruktory) musi także mieć zdefiniowaną syntaktykę czyli opis dozwolonych połączeń pomiędzy symbolami i opis znaczeń tych połączeń (to sie nazywa syntakytka notacji).

Jeżeli jakiś obieg dokumentu jest trudny do zamodelowania to
należy się zastanowić czy naprawdę dobrze rozumiemy cel procesu

Zgoda. Ale jeśli zastanowimy się, cel rozumiemy, a rzeczywistość będzie faktycznie skomplikowana ?

Osobiście przyznam, że znam tylko dwa przypadki kłopotu z zamodelowaiem procesu: nie zrozumiano procesu lub ukrywano prawdziwy cel procesu (czasem tym ukrytym celem jest to by po prostu istniał bo ktoś ma w tym interes ot choćby zajęcie).

>> 3. Czy zdarzyło się, że jakiś gotowy system obiegu (oczywiście >> bez nazw własnych !) nie spełnił oczekiwań, gdyż różnego
>> rodzaju zależności (właśnie - jakie ?) pomiędzy faktycznymi
>> procesami u klienta były zbyt trudne do wymodelowania w tym
>> systemie ?

Osobiściem nie zdarzyło mi się by jakis proces nie dał się zamodelować. Bywa, że wymaga dużo pracy odkrycie wartości jaką wnosi do całego łańcucha czynności... bywa, że nie wnosi :) i wtedy faktycznie jest ciężko. W kawestii systemów workflow na rynku zdarza się, że system taki nie pozwala na zaimplementowanie jakiegos procesu ale to wymaga (wybór systemu):
- sprawdzenia na co pozwala język modelowania procesu użyty w danym oprogramowaniu (sa takie które maja pewne ograniczeia i tu może sie zdarzyć, że wdrożenie sie nie uda)
- sprawdzic możliwości budowy interfejsów

Uważam, że obecnie system workflow bez możliwości budowania specjalnych interfejsów (webserwisy) może sprawić duże problemy integracyjne a nawet rozłożyc wdrożenie. Po drugie praktyka i literatura mi podpowiadaja, że we wdrożeniach systemow workflow należy już je traktowac jak zintegrowane systemy w architekturze SOA (architektura systemów IT zorientowana na usługi). Rzecz w tym, że większosć o ile nie każdy, proces w organizacji korzysta z jakichś istniejących zasobów IT i system workflow musi umieć z nich skorzystać. W przeciwnym przypadku, jeżeli w procesie choc jedna czynność dostępu do potrzebnych będzie musiała byc wykonana ręcznie cały system polegnie: damy ludziom precedens i "legitymację" do obchodzenia systemu.

Czy jednak owe Pana "nie raz" oznacza, że za każdym razem była to niezdrowa próba absurdalnej algorytmizacji, np. owego kopiowania dyskietek ?

Często niestety tak...

Wydaje mi się, że jednak niektóre problemy są obiektywnie trudniejsze niż inne i stworzenie dla nich modelu (myślę nadal o tzw "obiegach") może napotkać na prawdziwe problemy a nie te stworzone przez drobiazgowość.

Opisałem wyżej taki (chyba) problem, ewentualnie proszę o jakis przykład, możliwe że nie potarfie sobie wyobrazic tego o co Pan pyta...

Ośmielam się jednak ponowić prośbę o choćby jeden lub (lepiej dwa) przykłady prawdziwych problemów jakie wystąpiły w modelowaniu obiegów (choć pewnie tych stworzonych przez niwełaściwie dobraną perspektywę jest znacznie więcej).

Jak wspomniałem, napotkałem w audytowanych modelach kłopoty dwojakiego rodzaju:
- język modelowania nie radzi sobie z problemem (czesto spotykane, szczególnie niesty przy próbach użycia notacji UML do tego)
- proces ma ukryte cechy, nieodkryte przez analityka własciwości

ten drugi problem dotyka ogólnej teorii systemów, moim zdaniem niezbędnej do modelowania procesow biznesowych. Nalezy pamiętać, że proces zawsze funkcjonuje w jakims otoczeniu i ma pewne ograniczenia z niego wynikajace co wymaga przed modelowaniem procesów wykonania analizy systemu i jego zakresu oraz granic systemu, ktory będziemy modelować.

Najczęściej pojawiający się bład w obserwowanych przeze mnie modelach to proglem tak zwanej "pętli nieskończonej" oraz opisywany czasem w literaturze proglem "go to" (tu nie ma miejsca na ich opisywanie...).

Temat: tzw. obiegi dokumentów, pracy, ... itd

Witam Panowie;)
1. jeśli dobrze rozumiem to "konstruktor" jest programem umożliwiającym modelowanie procesów a konkretniej to rysowanie diagramów procesów oraz ich walidację, jak też prowadzenie w oparciu o nie symulacji.
Może nazwać to aplikacją do modelowania procesów (pracy).

2. "multi-merge, parallel split, synchronization, gateway..." = są nazywane bramkami (gateways)[np. BPMN]

3. Sprawa "trudności" modelowania procesu jest ciekawym zagadnieniem. Z moich doświadczeń problem nie leży w odwzorowaniu przebiegu realizacji czynności, zdarzeń i decyzji. Podzielam zdanie pana Jarosława, że problemem jest zrozumienie procesu oraz często ich ujednolicenie i standaryzacja w organizacji.

Temat: tzw. obiegi dokumentów, pracy, ... itd

1. jeśli dobrze rozumiem to "konstruktor" jest programem umożliwiającym modelowanie procesów

Użyłem tego jak widać nieszczesnego słowa "konstruktor" w innym znaczeniu, chodziło mi dokładnie o to co Pan nazwał bramką.

3. Sprawa "trudności" modelowania procesu jest ciekawym zagadnieniem. Z moich doświadczeń problem nie leży w odwzorowaniu przebiegu realizacji czynności, zdarzeń i decyzji. Podzielam zdanie pana Jarosława, że problemem jest zrozumienie procesu oraz często ich ujednolicenie i standaryzacja w organizacji.

Zgadzam się z oboma Panami, że najtrudniejszym elementem takich projektów jest człowiek. Mi chodziło o to, że w literaturze są dyskutowane pewne powiązania pomiędzy procesami (np. dyscriminator, M of N, itd) uznawane za trudne w realizacji. Rzeczywiście opisanie ich semantyki sieciami Petriego jest trudne. Interesowało mnie czy takie przypadki zdarzają się w codziennej praktyce. Częściową odpowiedzią jest, że jeśli dyskutują o nich naukowcy to na pewno tak ;) ale jest toodpowiedź chyba mocno częściowa ...
Pozdrawiam, Zdzisław

Temat: tzw. obiegi dokumentów, pracy, ... itd

ten drugi problem dotyka ogólnej teorii systemów, moim zdaniem

Czy może Pan doradzić jakąś dobrą książkę nt ogólnej teorii systemów ?

Najczęściej pojawiający się bład w obserwowanych przeze mnie modelach to proglem tak zwanej "pętli nieskończonej" oraz opisywany czasem w literaturze proglem "go to" (tu nie ma miejsca na ich opisywanie...).

Nieuchronność kłopotów z pętlą nieskończoną bierze się nie tyle z dziedziny modelowania systemów co jeszcze ogólniej z teorii rozstrzygalności : nie ma algorytmicznego sposobu żeby sprawdzić czy dany program się zatrzymuje (tzw problem stopu). Czyli trudność tkwi głeboko i na to żadne BPEL-e ani najlepsze "bramki" nie pomogą.
Pozdrawiam, Zdzisław

Temat: tzw. obiegi dokumentów, pracy, ... itd

Zdzisław Habasiński:

ten drugi problem dotyka ogólnej teorii systemów, moim zdaniem

Czy może Pan doradzić jakąś dobrą książkę nt ogólnej teorii systemów ?

Miałem jedną w ręku, wydanie lata 70te, napisana przez radzieckiego naukowca, całkiem niezła (nie licząc fajnych wstawek o marksiźmie...:)). Jak ją znajde dam znac. Dobra książka to "UML, inżunieria oprogramownia"... są tam elementy teorii komuniakcji i teorii systemów głównie inżynierii systemów, którą także polecam.

Najczęściej pojawiający się bład w obserwowanych przeze mnie modelach to proglem tak zwanej "pętli nieskończonej" oraz opisywany czasem w literaturze proglem "go to" (tu nie ma miejsca na ich opisywanie...).

Nieuchronność kłopotów z pętlą nieskończoną bierze się nie tyle z dziedziny modelowania systemów co jeszcze ogólniej z teorii rozstrzygalności : nie ma algorytmicznego sposobu żeby sprawdzić czy dany program się zatrzymuje (tzw problem stopu).

To sie rozwiązuje za pomoca modelowania ograniczen, w modelach biznesowych jest to moim zdaniem podstawowe narzędzie modelowania nie licząc ustalonej notacji. Sama notacja to tylko język, którym ja każdym językiem, można napisac stek bzdur lub poemat. Sama notacja nie rozwiązuje żadnego proglemu modelowania a tylko ewentualne problemy komunikacyjne.

Umieszczanie (wymóg) modelowania ograniczeń rozwiązanie problem petli nieskończonych i zmusza do poszukiwania (odkrywania) prawdziwych reguł biznesowych, najczęściej ukrytych w działaniach rutynowych i w kompetencjach ludzi.

Czyli trudność tkwi głeboko i na to żadne BPEL-e ani najlepsze "bramki" nie pomogą.

Z tym zgoda całowita, jak napisałem powyżej.
jz

P.S.
Co do literatury i szkoleń z modelowania: nauka teorii plus lata pracy w terenie :)

Temat: tzw. obiegi dokumentów, pracy, ... itd

>Dobra książka to "UML, inżunieria oprogramownia"... są tam elementy

teorii komuniakcji i teorii systemów głównie inżynierii systemów, którą także polecam.

Dziękuję. Poszukam jej.

Co do literatury i szkoleń z modelowania: nauka teorii plus lata pracy w terenie :)

Najpierw miałem teorię. Potem lata pracy w terenie . Teraz - obolały doświadczeniem - poszukuję dobrej, tj. praktycznej, teorii.
Pozdrawiam i jeszcze raz dziękuję za książkę.

Temat: tzw. obiegi dokumentów, pracy, ... itd

Zdzisław Habasiński:
Najpierw miałem teorię. Potem lata pracy w terenie . Teraz - obolały doświadczeniem - poszukuję dobrej, tj. praktycznej, teorii.

Książki:
- Podstawy ogólnej teorii systemów, PWN, 1978
- UML, inżynieria oprogramowania, Helion, 2007
- Podnoszenie efektywności organizacji, Rummler, Brache, PWE, 2000
- Zarządzanie wymaganiami, Leffingwell, Widrig, WNT 2003,
- polecam także koniecznie coś o sieciach Petriego

Nie znam żadnej monografii o modelowaniu procesów w sferze biznesowej. Osobiście z każdym rokiem dochodzę do wniosku że to sztuka i nie ma jednej dobrej jednej metody.

Temat: tzw. obiegi dokumentów, pracy, ... itd

Książki:
- Podstawy ogólnej teorii systemów, PWN, 1978
- UML, inżynieria oprogramowania, Helion, 2007
- Podnoszenie efektywności organizacji, Rummler, Brache, PWE, 2000
- Zarządzanie wymaganiami, Leffingwell, Widrig, WNT 2003,
- polecam także koniecznie coś o sieciach Petriego

Jeszcze raz dziękuję za wskazanie książek. Pierwsza będzie chyba b. trudna do dostania. Sieci Petriego znam. Mam wrażenie, że przydałby się koncepcyjnie inny model.

Nie znam żadnej monografii o modelowaniu procesów w sferze biznesowej. Osobiście z każdym rokiem dochodzę do wniosku że to sztuka i nie ma jednej dobrej jednej metody.

Wszystko co naprawdę trudne wydaje się być bardziej sztuką niż nauką. Tworzenie takiej nauki jak fizyka teżjest chyba bardziej sztuką. Naukę tworzą z niej dopiero akademiccy powtarzacze dla pierwszego roku studiów...
Pozdrawiam, Zdzisław H.

Temat: tzw. obiegi dokumentów, pracy, ... itd

Zdzisław Habasiński:
chyba b. trudna do dostania. Sieci Petriego znam. Mam wrażenie, że przydałby się koncepcyjnie inny model.

Jaki i dlaczego nie sieci Petriego? Jest kilka ich klas ... teoria grafu skierowanego moim zdaniem doskonale nadaje sie do modelowania procesów biznesowych i nie tylko... sama notacja tych sieci nie rozwiązuje oczywiście problemu jednak np. taki BPMN to notacja oparta na grafach skierowanych podobnie zresztą jak eEPC w Arisie.

Temat: tzw. obiegi dokumentów, pracy, ... itd

Jarek Żeliński:

Zdzisław Habasiński:
chyba b. trudna do dostania. Sieci Petriego znam. Mam wrażenie, że przydałby się koncepcyjnie inny model.

Jaki i dlaczego nie sieci Petriego? Jest kilka ich klas ... teoria grafu skierowanego moim zdaniem doskonale nadaje sie do modelowania procesów biznesowych i nie tylko... sama notacja tych sieci nie rozwiązuje oczywiście problemu jednak np. taki BPMN to notacja oparta na grafach skierowanych podobnie zresztą jak eEPC w Arisie.

W sieciach Petriego trudno modeluje się zależności czasowe pomiędzy procesami (np. bramki typu "milestone" lub "discriminator"). Jeśli to Pana interesuje to prześlę na prv artykuły naukowe, które te problemy ilustrują i jakoś rozwiązują ale - na moją intuicję - w dość skomplikowany sposób.
Prostsze byłoby użycie grafów oraz prostych formuł tzw. modalnej logiki zdań. Ot temat na kolejny doktorat.
Pozdrawiam, Zdzisław Habasinski

Temat: tzw. obiegi dokumentów, pracy, ... itd

Zdzisław Habasiński:

Jarek Żeliński:

Zdzisław Habasiński:
chyba b. trudna do dostania. Sieci Petriego znam. Mam wrażenie, że przydałby się koncepcyjnie inny model.

Jaki i dlaczego nie sieci Petriego? Jest kilka ich klas ... teoria grafu skierowanego moim zdaniem doskonale nadaje sie do modelowania procesów biznesowych i nie tylko... sama notacja tych sieci nie rozwiązuje oczywiście problemu jednak np. taki BPMN to notacja oparta na grafach skierowanych podobnie zresztą jak eEPC w Arisie.

W sieciach Petriego trudno modeluje się zależności czasowe pomiędzy procesami (np. bramki typu "milestone" lub "discriminator"). Jeśli to Pana interesuje to prześlę na prv artykuły naukowe, które te problemy ilustrują i jakoś rozwiązują ale - na moją intuicję - w dość skomplikowany sposób.
Prostsze byłoby użycie grafów oraz prostych formuł tzw. modalnej logiki zdań. Ot temat na kolejny doktorat.
Pozdrawiam, Zdzisław Habasinski

Właśnie ukazała się książka WNT, 2008 "Sieci Petriego w modelowaniu i analizie systemów ", są tam opisy modelowania systemów współbieżnych, polecam właśnie czytam.

Po drugie same sieci petriego i notacje do tego służące nie nadają się do modelowania biznesu ale notacje i systemy bazujące na nich (teoria grafów skierowanych) już moim zdaniem tak.

Temat: tzw. obiegi dokumentów, pracy, ... itd

Właśnie ukazała się książka WNT, 2008 "Sieci Petriego w modelowaniu i analizie systemów ", są tam opisy modelowania systemów współbieżnych, polecam właśnie czytam.

Dziękuję za kolejną ciekawą informację.

Po drugie same sieci petriego i notacje do tego służące nie nadają się do modelowania biznesu ale notacje i systemy bazujące na nich (teoria grafów skierowanych) już moim zdaniem tak.

Chyba chciałem wyrazić podobną myśl. Sieci P. nie są konieczne aby za pomocą grafów skierowanych modelować procesy. Wydaje mi się, że grafy skierowane + pewne formuły logiczne załatwiają sprawę nawet lepiej.
Pozdrawiam, ZH

Temat: tzw. obiegi dokumentów, pracy, ... itd

Zdzisław Habasiński:
Sieci P. nie są konieczne aby za pomocą grafów skierowanych modelować procesy. Wydaje mi się, że grafy skierowane + pewne formuły logiczne załatwiają sprawę nawet lepiej.
Pozdrawiam, ZH

Jestem tego samego zdania :)