24. 3. 2008

Soustava a procesní uzel

Jedna plující loď představuje jeden proces. Jedna řeka představuje jednu pipelinu. Řeka včetně přítoků představuje celou soustavu. Řeka má několik přítoků a každý takový přítok vypadá úplně stejně jako hlavní řeka. Plují po ní lodě s kontejnery s jediným cílem, dovézt co nejrychleji do cíle zboží, které bude naloženo v přístavech po cestě.

Soustava je vlastně „soustavou“ dekomponovaných pipelin, které jsou propojeny řadou logických vazeb s procesními uzly, grafické znázornění nejlépe vystihují obrázky 2 a 8.

Procesní uzel je místo, důležité hned z několika důvodů. Především zde najdeme rozhraní/přechod mezi dvěma procesy, kdy se střetávají výstup z jednoho procesu se vstupem procesu jiného, obr. 7. Větší pozornost toto místo zaslouží také proto, že na každé straně uzlu stojí různé osoby, většinou jiného postavení, zaměření či podnikové hierarchie. Tento vzájemný vztah můžeme zpravidla chápat také jako vztah dodavatel-zákazník, lépe pak porozumíme pravidlům spojeným s procesním uzlem.

Jako názorný příklad si vezměme objednávku zboží. Výstupem jednoho procesu (zákazníka) je dokument popisující řadu atributů typu objednávající firma, zodpovědná osoba, položky objednávky, doba dodání, adresa dodání, atd. Vstupem druhého procesu (prodejce) je přijetí objednávky formou zaevidování potřebných údajů a vystavení potvrzení o přijetí objednávky. Zdá se, že atributy objednávky si diktuje zákazník, pravda je ovšem jiná. Dodavatel je zodpovědný za správnou definici atributů a úplnost objednávky tak, aby mohl realizovat svůj proces k plné spokojenosti zákazníka.

Kliknutím obrázek zvětšíte
Obrázek 7: Procesní uzly

Každé rozhraní, tedy i rozhraní mezi procesy, je potenciálním zdrojem chyb, nedorozumění a nekompatibility. V konečném důsledku to neznamená nic menšího, než vysoké náklady na kontrolu a následné opravy. Proto je potřeba této oblasti věnovat mimořádnou pozornost.

Veškeré náklady, které jsou spojeny se zpracováním, kontrolou a vyřízením všech aktivit mezi dvěma procesy, nazývejme transakčními náklady. Procesní uzel je přesně to místo, kde se o transakční náklady “hraje”. Je velmi důležité shodnout se na tom, která strana ponese jaký díl těchto nákladů a která strana je zodpovědná za “přesné zadání”.

Ten, kdo se jenom trochu pohybuje ve světě procesů, si dokáže představit velikost všech nákladů spojených s chybou na vstupu, kterou se nepodařilo odhalit včas. Veškeré návazné činnosti jsou vstupní chybou zatíženy, náprava je často spojená s rozhodnutím vrátit proces na začátek, ovšem ztracený čas už nejde nikdy nahradit.

Obrázek 8 znázorňuje příklad typické firmy, která se zabývá zakázkovou výrobou. Je zde zřejmé logické rozložení jednotlivých pipeline a umístění procesních uzlů mezi nimi.

Kliknutím obrázek zvětšíte
Obrázek 8: Pipeliny podniku s uzly

Glosář

17 Comments:

Anonymní said...

Tomáši, myslím že děláte svým názorným výkladem docela slušný pojmonelogický zmatek.

Už minulý díl jsem byl v pokušení komentovat - zejména zmatečné označování pipeline a dokonce jeho přeložení jako "datovodu". Data opravdu nejsou v procesech to, o co kráčí.

A v díle tomto:
"Plující loď představuje jeden proces." Proces je řeka či pipeline či ona soustava. Loď může být jen jednou instancí - průběhem procesu.

A dále - proč při použití analogie řeky a lodí zavádíte zcela nesourodý pojem "uzel"? Navíc poněkud zmatlaně. Buď jde o rozhraní mezi procesy nebo jde o procesní fragmentaci (organizační, IT...). Každý z těchto případů je úplně jiný (byť může v praxi vykazovat shodné zhoubné symptomy) a musí se řešit jinak.

Výčitka třetí - transakční náklady je pojem zavedený (souhrn nákladů na soubor nepřerušitelných návazných operací). Zde ho používáte ve smyslu náklady na rozhraní (nebo fragmentaci).

Každý strukturovaný přístup, který aspiruje na to, aby byl označen za metodiku, by měl začít vyčištěným názvoslovím. Prosím - napravte to!

Anonymní said...

Taky si lehce přisolím. Obrázek 7 a jeho popis páchne funkčním pohledem na firmu. To přece nejsou nějaké dva procesy. Existuje jen jeden end-to-end proces, který začíná požadavkem zákazníka a končí jeho uspokojením. Že prochází řadou organizačních útvarů je šumák. Uzly vznikají právě funkčním přístupem.

Anonymní said...

Romel: "proč při použití analogie řeky a lodí zavádíte zcela nesourodý pojem "uzel"?"

Pojem UZEL mi připadá velmi názorný a emocionálně silný, což je také dležité. Je pravda, že do vizualizace procesu jako řeky moc nehodí - což takhle jez s plavební komorou?

Anonymní said...

K Romelovi - metodicky to možná čisté úplně není, ale o to tady asi nejde, když - jak už tu bylo několikrát řečeno - jde o analogii.

Jinak k Tomášovi a soutěži o flašku za lepší procesní analogii:

Já z výroby jsem. Proto myslím, že nejlepší obraz procesů je právě výrobní hala se stroji. Netřeba vytvářet obrazy vzdálené - stačí se jít podívat do první výrobní fabriky a pojem proces je úplně jasný!

tomas said...

Milý Romele, začnu od konce Vaší připomínky. Názvosloví beru za absolutní základ pro "dorozumění se", pro seriál TEP tedy existuje Glosář včetně analogií. Pokud znáte stejné výrazy v jiném smyslu, s tím bohužel nic neudělám. Beru výčitku v momentě, kdy bude nesoulad mezi textem a Glosářem.
Vaše věta "Data opravdu nejsou v procesech to, o co kráčí." je pro mě zcela záhadná. První co mě napadá, je zásadní otázka: Jak můžu řídit proces bez dat/informací?!? TEP je primárně založena na rozhodování/řízení na základě dat, a to především na časech dosažených stavů. Nebo mluvíme každý úplně o něčem jiném?

tomas said...

Přisolící Kosi, ano, v podstatě existuje jen jeden end-to-end proces tak jak jej popisujete. Ovšem kouzlo TEP je v tom, že dokáže tento jeden proces dekomponovat na potřebné množství (sub)procesů tak, aby byla větší efektivita celku, a o to jde především!

tomas said...

Anonymnímu děkuji za pomoc, nicméně se budu muset polepšit v tom, že vysvětlení bude jasně "analogické" s lodičkami, přístavy apod. nebo "abstraktní" s procesy. Evidentně se někdy směšují pojmy i grafické znázornění ...

tomas said...

Oswald si ještě flašku nevysloužil, možná tak malou štamprli. Zkuste dostat pár bankéřů, státních úředníků či programátorů v rámci prezentace TEP na exkurzi do výroby. Jednak na to nemají čas, jednak si nemyslím, že souvislosti s jejich vlastními procesy by byly zřetelné. Věřím, že je potřeba především grafické vizualizace....

Anonymní said...

Je pořád snažší dostat úředníky a bankéře do fabriky než na řeku:)

Anonymní said...

Proces je tok přidané hodnoty. Nebo jinak - nejkratší sekvence činností přidávajících hodnotu do výstupního produktu (služby).

V procesu tedy nejde PRIMÁRNĚ o data, informace. To, že činnosti potřebují k tomu, aby byly provedeny, nějaké I/O, je jasné. Někdy to I může být nejen vstupem, ale i zdrojem a měnit se na přidanou hodnotu.

Na co jsem narážel já - aby se nezaměnil tok procesu s tokem informací. Téměř nikdy to není totéž. Což zejména IT lid velmi obtížně chápe.

Ve Vaší vizualizaci není pro informace zatím viditelné místo. Možná to bude jejím nejslabším bodem, protože neumožňuje názorně odlišit tok dat a tok hodnoty.

Anonymní said...

A ještě ke glosáři - tam si samozřejmě můžete napsat, co chcete. Je otázkou, zda je účelné měnit sémant u zavedených pojmů.

Anonymní said...

Tomas wrote: "...kouzlo TEP je v tom, že dokáže tento jeden proces dekomponovat na potřebné množství (sub)procesů."

Nevím, co je to za kouzlo, tohle je podstata notace BPMN (možnost vytvářet libovolně vzájemně konzistentní subprocesy) i dalších zcela běžných metodik.

Moje připomínka byla o nevhodně použitých pojmech - proces / subproces. Mluvím teď z praxe:

Jakmile uděláme z nějakého subprocesu (většinou organizačně vymezeného tak, jako to máte Vy na obrázku) proces - tedy cíl sám o sobě, velmi posílíme organizační bariéry na jeho rozhraních.

A ještě k tomu Vašemu uzlu. Představa uzlu (který většinou něco svazuje) není moc pedagogicky chytrá - mnohem lepší je zeď, bariéra, překážka. Když uzel rozetnete jako A.V., dojde k porušení procesu, když ho rozvážete, máte tam dva volné konce. Když zbouráte zeď, může tam vést cesta.

Anonymní said...

Uzel může taky být jen tak - prosté zašmodrchání. O to tu kráčí, Kosi (nebo Kose?).

tomas said...

Romelův tok dat oddělený od toku hodnoty (tok informací versus tok procesů) je pro mne naprosto falešným pohledem na věc. Co to znamená tok dat na rozdíl od toku hodnoty? Každý míří někam jinam? Nejsou na sobě sávislé? Tyto dva toky najdu úplně někde jinde?
K těm zavedeným pojmům o procesech, kde najdu nějaký všemi respektovaný slovník?

tomas said...

Mohl by Kos ozřejmit větu "Jakmile uděláme z nějakého subprocesu (většinou organizačně vymezeného tak, jako to máte Vy na obrázku) proces - tedy cíl sám o sobě, velmi posílíme organizační bariéry na jeho rozhraních."??
Nejlépe vysvětlujícím názorným příkladem, děkuji.

Anonymní said...

Mohu uvést zrovna příklad Nákupu, který na obrázku uvádíte. Pokud prohlásím Nákup za samostatný proces, vyvolám (nebo podpořím, pokud již existují) tyto požadavky:

- samostatné organizační zajištění (např. vznik sekce Nákup), navíc toto organizační zajištění se bude vydávat za "procesní organizační uspořádání"

- formalizaci předávaných informací a vznik pevně měřitelného rozhraní Nákupu, např. formou SLA

Jenže - nákup je zapojen do několika procesů a pokaždé jinak, např.

- proces Výroba na zakázku
- proces Standardní produkce
- proces Životní cyklus investice...

Kde nastanou problémy?

1) Nákup se bude snažit vyřizovat všechny požadavky stejným způsobem, nebude brát ohled na specifika daného procesu.
2) Nákupní požadavky se budou kupit ve frontě v nákupu, ztrácím přehled o proůběhu procesů, bude obtížné dohledat jednotlivé případy, při vyřizování nebude brán zřetel na potřebu procesu, ale na zatížení nákupu.
3) Nastane problém s likvidací faktur (další pevné rozhraní na Finance).

Výše popsané je moje osobní zkušenost, realita byla ještě brutálnější, než jsem zde uvedl.

tomas said...

Teď už zcela rozumím KoSovi o co jde. S podobnými příznaky se setkávám denně. Vidíme zde řadu provázaných a souvisejících momentů s nežádoucímy efekty. Museli bychom to rozmotávat bod po bodu a na to zde bohužel není místo, tohle by chtělo osobní konzultaci. Doufám, že bude někdy příležitost.

ISSN 1802-5676  | Copyright © 2003-2007 BPS Business Process Services