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.

"Neboli se snažíme o to, aby značná část našich procesů měla system-intensive charakter, a my tak uvolnili energii pracovníků pro tvůrčí řešení problémů." - treba tohle je docela husta veta

Tak jestli do toho muzu decanko vstoupit, tak na uvod asi nasledujicim zpusobem:
BPM je jedna z veci, o kterych se krasne pise, a ve kterych se da chodit v krasnych bludnych kruzich.
Pokud se o BPM uvazuje, mel by se clovek nejdriv ujasnit, jaky je jeho vychozi stav, a do jakeho stavu se chce dostat. Ono to totiz neni v zadnem pripade o softwaru, ktery je jenom doplnkem, a ktery by mel byt as tim poslednim stupnem, ktery bude spise nastolene zmeny podporovat.

Jinak pokud muzu doporucit, pak platky typu Business World a System Online brat s velkou reservou, je to jenom obchodnicky Sales Pitch...

Pokud mate nejake dotazy, rad zodpovim.

Kdyz uz jsem to ted byl nucen mirne nastudovat, tak pridam odkaz na jeden - IMO bohuzel dost pravdivy - popis pouzivane technologie:
http://archive.eiffel.com/doc/manuals/technology/bmarticles/uml/page.html

A ve vaznejsim duchu - pokud nekdo uvazuje o aplikaci techto reseni v podniku, vyhnete se velkym obloukem novym nastrojum od CA. Vetsi slepenec aby clovek opravdu pohledal. S jinymi jsem nemel jeste tu cest, nevylucuji, ze takovato vec jde udelat i tak, aby efektivitu procesu ve firme nesabotovala...