31. 3. 2008

Postup zavádění TEP

Detailní postup zavádění efektivních procesů není součástí tohoto pojednání. Popis každého z kroků vydá na samostatnou stranu či kapitolu.

Pro základní představu nyní postačí stručný přehled:

  1. Definuj množství a typy procesů a popiš je - zjisti kolik mají společných prvků (stavů, formy vstupů a výstupů)
  2. Definuj stavy procesů (na počtu "záleží"!), vytvoř pipy a urči majitele každého procesu a zároveň majitele pipeliny
  3. Definuj procesní uzly/vstupy a výstupy, věnuj jim mimořádnou pozornost! Zde se nejvíce redukují transakční náklady
  4. Definuj periodu aktualizace stavů


Uvádím zde také několik doporučení spojených s konkrétními kroky při nasazování TEP.

Doporučení č. 1
Vždy měj na mysli zájmy jednotlivých účastníků procesu, nikdo neudělá nic, co je nad rámec jeho povinností, co nemá dopad na jeho výsledky!

Doporučení č. 2
Procesy musí být popsatelné, mapovatelné, čitelné, dohledatelné a měřitelné!

Doporučení č. 3
Nesnaž se dostat veškeré procesy ve firmě do jedné pipy, je to pokus o "řízení neřiditelného"!

Doporučení č. 4
Reference neboli ID procesu -evidovat všechny procesy v rámci podniku jednou číselnou řadou je nereálné, je to pokus řídit neřiditelné, jedna řada znamená jeden typ procesu = stejné stavy, parametry. Jedna jediná řada přináší množství informací, jejichž využitelnost a vyhodnocování je velmi problematické.

Doporučení č. 5
Překonej odpor podřízených, kteří nechtějí dělat záznamy o stavech procesu, nebo zaznamenávat podstatné informace. Výmluva na to, že se jedná o nadbytečnou byrokracii, je falešná. Tato “nadbytečná byrokracie” umožní rozhodovat efektivně.

Glosář

26 Comments:

Anonymní said...

Vím, že jste uváděl, že je možné TEP dělat v "čemkoliv". Přesto - existuje nějaký nástroj, ve které je máte osobní zkušenost, že se procesy snadno definují?

Anonymní said...

Provádět popis toku vlastních procesů se provádět nemá? Nebo je to myšleno tím"vytvoř pipy"?

Anonymní said...

Co se myslí "stavy procesů"?

tomas said...

Korbelovi i Baltimovi tedy více příblížím, co a proč používám.

a) pro popis a znázornění soustavy používám Visio (stačil by ale i Word) - například pro znázornění Obr.8 stačí bohatě sada Graf.symboly .Tento pohled je naprosto zásadní z celé řady důvodů, uvádím jen ty nejdůležitější:
- je jasná odpovědnost jednotlivých osob za příslušné procesy/pipeliny
- vidíme toky procesů celou firmou popř. oddělením
- vidíme procesní uzly (kritická rozhraní mezi procesy)
- pěkně se zde analyzují interakce procesů a oddělení ve firmě

b) na procesní diagramy používám Visio, v zásadě ale stačí také Word, který obsahuje v sadě Vývojové diagramy potřebné grafické znaky
- tento pohled je důležitý především kvůli časové návaznosti kroků v procesu a pak na odhalení "slepých cest" a nelogičností

c) pro zobrazení Pipeline používám Excel
- lze zde velmi dobře simulovat výstupní pohled na pipelinu
- lze si hrát i s dynamikou procesů, vyčíslovat průtoky, úzká místa, priority atd.

tomas said...

Verunce bych s dovolením přípomněl, že pro vysvětlení nejen výrazu stav procesu existuje Glosář.
Stavy jsou ovšem klíčovým atributem pro TEP. Pracovat s dynamikou procesů lze jen a pouze na základě stavů. Pokud bude potřeba, dovysvětlím, prosím však o co nejkonkrétnější dotazy.

Anonymní said...

Asi by to chtělo fakt nějaký příklad.

Anonymní said...

Glosář jsem četla, ale stav procesu mi jasný není - jde obecně o všechny body (místa transformace nebo jak to nazvat), kterými proces prochází. Nebo se myslí časové okamžiky, kdy jsou tyto body dosaženy? A vůbec - ty přístavy - jde o každý vstup/výstup z procesu nebo jen o některé? A jak pak poznám, které jsou důležité a které ne?

Anonymní said...

To visio používáte, Tomáši, s nějakou procesní nadstavbou nebo čistě jako obrázkoment?

tomas said...

obrázkoment...

tomas said...

Verunko,
Stav je v Glosáři definován jako "Jednoznačný milník, kterým proces prochází". Jako příklad můžeme použít proces obchodní případ. Dosežením stavu se pak myslí např. datum zaslání nabídky nebo datum přijetí objednávky. Jednotlivé stavy je potřeba definovat jednoznačně aby nebyly možné různé výklady, potom by vše ztrácelo měřitelnost.
V lodičkové analogii je stavem "Moment naložení kontejneru v přístavu", tzn. přesné datum, kdy je naloženo. Loď potom pluje dále do dalšího přístavu, kde je znovu naložena a tím dosáhne nového stavu.
Pokud navrhuji pipelinu, musím určit počet stavů tak, aby každý proces musel vždy projít všemi stavy v rámci této pipy .

Anonymní said...

Už udělat bod 1 si nedokážu představit. Jakou formou by to mělo být uděláno? Jako nějaký tabulkový soupis?

tomas said...

Může to být tabulkový soupis atributů již uvedený v časti Proces
* Vstup - Co vyvolá/zapříčiní zahájení procesu
* Výstup/účel/cíl/ - Co má být dosaženo a proč
* Aktivity - Činnosti naplňující výstup procesu
* Role (zákazník (interní, externí), vlastník) - Které role jsou dány, jejich zodpovědnosti, jejich zájmy
* Uspořádání/Stavy/Struktura – Které fáze a sekvence se během procesu uplatňují
* Zdroje - Nutné náklady na průběh procesu
* Metriky - Konkrétní číselné měřené hodnoty určené pro další zpracování

Anonymní said...

Dovedu si představit, jak bude takto vytvořený popis (obrázky ve visiu, tabulky v xls) pěkně konzistentní:(

Proč nepoužíváte aspoň jednoduchý modelovací nástroj? Už jich je dost zadarmo a docela kvalitních - šla o tom řeč tady v blogu někdy před 2 měsíci. Bez repository, kde mám jeden objekt jednou definovaný se všemi potřebnými atributy a můžu ho používat v různých kontextech, je jakýkoliv popis procesů pěkná šílenost.

Možná se to ještě dá použít jednorázově na nějakém projektu zlepšení, ale rozhodně se to nedá používat na průběžné zlepšování.

Anonymní said...

Tomáši, co je to vlastně za NOTACI, kterou tady prezentujete? Nějaká Vaše zcela vlastní nebo je to nějaká varianta na BPMN/EPC/UML?

Anonymní said...

Upka a Olina už vlastně řekly, co jsem se chtěl zeptat. Takže to jenom shrnu:

1) Proč pro popis procesů nepoužíváte nějakou zavedenou metodiku (či notaci podle Oliny)?

2) Proč pro popis procesů nepoužíváte nějaký vhodný nástroj?

Anonymní said...

A odklepl jsem to dřív, než jsem dopsal svoje:

3) V čem je Váš specifický přístup lepší, než použití zavedených standardů?

Anonymní said...

Souhlas s ukou, olinou a robbim. Připadá mi to jako návrat stromy.

Anonymní said...

Pořád jsem zmatena s těmi stavy procesu. Míní se tím události /eventy?

tomas said...

Upce, Oline, Robbimu, Anonymnímu
Rozhodně se nevyhýbám modelovacím nástrojům, hledám vhodné a dost pozorně sleduji tento web. Zatím jsem je ale nutně nepotřeboval. Nicméně i bez sofistikovaných nástrojů si dovolím zde prohlásit, že procesy změnit, nastavit a změřit dokáže každý průměrně zasvěcený manažer. Klíč je v pochopení problematiky.

Používám svoji vlastní NOTACI či postupy, možná chybí dokonalost ale funguje velmi dobře. Důkazem budiž třeba zvyšování produktivity práce v našem oddělení o 50% ročně!

A s těmi stromy, Anonyme, myslíte že je potřeba vždy používat ty nejdražší nebo nejlepší nástroje?
Nedávno jsem měl s kolegou malou polemiku o tom, jestli je potřeba nejprve koupit ten nejdražší nástroj (rozuměj sw) a pak teprve se s ním učit zacházet. Odpověď asi tušíte. Stojím si za tím, že nejprve je potřeba umět s věcmi/procesy zacházet, a pak si teprve pořídíme ty nejvhodnější (třeba i nejlepší) nástroje. Tímto postupem dosáhneme největší efektivity, nikoliv opačně!

tomas said...

Verunko, Vy mě provokujete až k individuálnímu školení! Budiž, navrhnutý termín pošlete raději mailem, potřebujeme klid na práci.

Anonymní said...

Eh - pro svou vlastní notaci žádný SW zadarmo asi nenajdete. Jinak souhlasím, že žádný nástroj nevede AUTOMATICKY k pochopení procesů a že je důležitější pochopit procesy věcně než se učit ovládat nějaký nástroj.

Ale tvrdím, že je NUTNÉ využívat existující standardy. Nejen kvůli tomu, aby člověk nemusel objevovat ameriku, ale i kvůli přenositelnosti a propojení na další systémy (minimálně na case).

Anonymní said...

Stromy myslím kreslítko visio, když jsou k dispozici modelery úplně zdarma (což visio ani excel není!) a s ještě jednodušším ovládáním.

A k tomu zvyšování produktivity - kolik let za sebou už meziročně zvyšujete produktivitu o 50%?

Anonymní said...

Vidím, že se to tu zvrhává na boj kresličů (názorných schémat) s modelery (s pevnou metodikou).

Co já k tomu? Až do loňska žádný standard ani de-jure ani de-facto neexistoval. Bylo možné použít buď velmi dobrou metodiku aris nebo qpr nebo uml, ale vždycky spojenou s nějakým konkrétním a pěkně mastným nástrojem. A ani takováto metodika občas neumožnila nakreslit úplně všechno a přehledně. Příklad - malovat v arisu přehledový model aplikací s informačními toky je příšernost, dodnes to radši načmárám v powerpointu.

Výše uvedení rebelové však mají pravdu, že se loni situace diametrálně změnila - existuje BPMN/BPD a na implementační úrovni BPEL, což umožňuje triviálně malovat procesy. Nástrojů zadarmo nebo za hubičku přibývá a letos bude opravdu poprvé znažovat, zda zaplatíme údržbu licencí našeho dokonalého nástroje nebo ho vyměníme za open source s pořádnou placenou podporou.

Pořád ale ještě zbývá spousta procesního kontextu, které v BPD nenamalujete takže proč se pohoršovat, že si je Tomáš čmárá po svém?

tomas said...

Stromy=Visio, to vidím/slyším poprvé, myslel jsem že Anonymnímu vypadlo slovo "na" před slovem "stromy", takže se omlouvám.
Jsem ve firmě dva roky od března 2006, a nárůst produktivity vypadá takto:
2005 -13%
2006 21%
2007 50%
Detailní statistiky ale nevyměnil ani za pravou identitu Anonymního...

tomas said...

S Robbim souhlasím, samozřejmě jsem pro standardizaci. Jako ve všech jiných oborech nakonec zbudou dva tři "jazyky" kterými se lidé jednoho oboru mezi sebou dorozumí. Netušil jsem však, že až tak moc bude kladen důraz na tuto oblast.
Prozradím tajemství č.2, čekal jsem, že zde budu spíše "krájen na kusy" kvůli jádru věci, tedy principům myšlenky TEP...

tomas said...

Děkuji Náhlíkovi za podporu, navedl mě na následující myšlenku:

Začnu ale nejprve trochu ze široka... před časem jsme začali implementovat NORIS/Helios Green. Během konzultací ale nastal poměrně značný rozpor s pohledem na procesy, konzultant prosazoval již ověřené a "zabudované" procesy, já chtěl TEP s pipelinami, měl jsem ovšem výhodu pozice zákazníka... Konzultanti LCS na mě vytáhli svůj vlastní procesní modelář ve Visiu, který se mi líbil už od začátku (dodnes občas použiju), je jednoduchý, srozumitelný, informačně bohatý, naprosto dostačující. Nakonec jsme se domluvili (dodnes vidím velmi pochybovačný výraz konzultanta), že připravím do příštího sezení kompletní zadání pro naše oddělení v jejich nástroji. Výsledek byl takový, že stačilo "jejich" Visio a "můj" Excel k tomu, abychom během 2 celodenních sedáncích ve 2 lidech naimplementovali 2 klíčové firemní pipeliny (zakázky a obchodní případy) včetně napojení na okolí.

Chci tím říct, že začnu pracovat (především kvůli srozumitelnosti) na realizaci TEP v jednotlivých standardech na konkrétních příkladech... když to šlo v jednom nástroji, musí to jít i v jiném.

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