no ja bych urcite diskuzi na toto tema ocenil:)

Zajima jeste nekoho tohle auditko?
Co treba probrat nejaky zkusenosti s implementaci workflow, problemy na ktery jsme narazili, v jakych nastrojich jste modelovali, tvorili workflow? Bezi vam neco v produkci, na cem?

Máte někdo nějaký ověřený free nástroj pro tvorbu procesních map?

Pozor pozor: http://www.serena.com/mashups/index.html

Mam k dispozici betaverzi k testovani a vypada to dobre. Spousta zajimavych rozsireni puvodniho konceptu...

SUCZKER: rekl bych ze to je souvisejici tema :o) ale rozhodne to neni nic dulezityho :o)

ale to uz odbihame od tematu (ktere je vlastne jake ? - ceho se chceme dobrat) ke sporu o malovani ;) takze toho doporucuju nechat.

SUCZKER: pokud to neni prehledny tak je to spatne. Treba tohle mi prijde uplne v klidu a po peti minutach se v tom musi zorientovat i nekdo kdo v zivote nic podobneho nevidel:
http://www.serena.com/images/products/changeMan/tt4zmf-screen2.gif

Samozrejme nikde neni psano ze si k tomu neMUZES VEPSAT POZNAMKY A POPISY.

Navic slozitejsi workflows se rozdeluji na vice casti ktere se pak propojuji dohromady a je to prave proto aby vse bylo jednoduche a prehledne.

Mozna ti to prijde divne, ale pro me je lepsi udelat jednu petisetstrankovou technickou specifikaci, kterou je mozne udrzovat a delat v ni revize a ve ktere je napsano vsechno, nez kreslit diagramy, kde se neda dodatecne zjistit co to dela. Ale tim naprosto neminim, ze to delas spatne, nebo ze ja to delam dobre.

No, to se asi neshodneme. Problem je v tom, ze ve workflow, jakmile si ho z obrazkujes, se ti ztrati spousta dulezitych informaci, a kazdy ho muze pochopit trosku jinak. To je moje osobni zkusenost a tys samozrejme mohl udelat uplne jinou. A mozna ze ja casem jeste taky udelam jinou ;).

...Tezko...

SUCZKER: na modelovani workflow je diagramovani nezbytna vec a myslim ze je to tak dobre. Slozite veci je lepsi vizualizovat aby byly snaze pochopitelne. Tesko textove popises slozite workflow ktere ma treba 50 ruznych stavu a jeste vice prechodu mezi nimi...

SUCZKER: To jsi me nepochopil presne. Proces uzivatele nemohou ovlivnovat. Ten je presne definovan tim kdo jej analyzoval a nasledne vytvoril model. Uzivatel jen doplnuje informace behem pruchodu procesem. Napriklad na helpdesk prijde incident od uzivatele ktery ma problem s pocitacem (pocitac nefunguje a nevi proc). Vedouci pracovnik problem prideli nekteremu z operatoru k reseni. Operator zavola uzivateli a na zaklade rozhovoru s nim doplni data ktera knkretizuji dany problem a provede prechod do dalsiho stavu.... a takhle se postupne nabiraji a doplnuji informace dokud to nepropadne celym workflow do stavu "vyreseno". Samozrejme konecny stav muze byt i zamitnuto, uzavreno, predano k reseni dodavateli atp.

Muj nazor na diagramovani vystihuje velmi dobre tento clanek: http://www.regdeveloper.co.uk/2007/08/16/verity_stob_software_diagramming/

BRAINLOAD: nechat uzivatele, aby si sami popisovali proces je bohuzel stejna kravina, jako nechat koncaky, aby si sami navrhovali software. Bohuzel past je v tom, ze to chce vzdy nekoho znaleho problematiky, protoze cistej IT-ik si prave casto neuvedomuje ty sideefekty.

Jinak ja jsem zasadne proti malovani obrazku, diagramu a grafu, a jsem pro cistou textovou, dostatecne podrobnou dokumentaci, do ktery je mozny kdykoliv hrabnout a udelat revizi.

BRAINLOAD: To mi pripomina: "Hello, IT. Did you tried to turn it off and on again?" :-DDD

SUCZKER: jj, to je presne ono. Taky je sranda kdyz nechas uzivatele aby sami zadavali incidenty. Nejlepsi je nechat je vyplnit nazev a popis a zbytek zjisti a doplni operator. Pokud das uzivateli volnou ruku tak je z toho peklo :o)

BRAINLOAD: To je prave to, o cem tady jde rec. Ve skutecnosti potrebujes pohled pres celou firmu. Ftip je, kdyz ti pak odbory vzkazou, ze ridici dodavek s sebou zadnej papir s carovejma kodama a scanner tahat nebudou, a ze jestli jo, tak budou stavkovat, a podobny srandy.

Samozrejme, jak pises, sladit soucinnost a navaznost tech jednotlivych procesu je casto problematicke prave kvuli ruznym side efektum, ktere v nekterych pripadech puvodni zpusob prace mel ;).

Ja mam treba s teamtrackem dobre zkusenosti. O tuto problematiku se sice nezajimam nikterak dlouhou dobu, ale i tak mam myslym dobry prehled problematiky a musim rict ze Teamtrack me dosti zaujal.
Samozrejme zalezi na zpusobu implementace. Software sam o sobe je k nicemu pokud administratori nejsou schopni analyzovat a nasledne efektivne namodelovat procesy za pouziti tohoto software tak, aby vysledkem bylo zlepseni soucinnosti jednotlivych organizacnich slozek spolecnosti. Dost zalezi na organizacni strukture spolecnosti a na tom co je predmetem jeji cinnosti.