Jaká vidíte omezení použití principů TOC a CC v řízení projektů IS/ICT?

Připravená úvaha na téma “Jaká vidíte omezení použití principů TOC a CC v řízení projektů IS/ICT?” na předmět “Řízení projektů IS/IT”.

Jelikož CC vychází z TOC, tak nebudu rozdělovat na dvě části a budu popisovat omezení dohromady. Jedním zřejmým omezením použití principů TOC a CC(PM) vidím v tom, že může nastat případ, kdy kritický řetěz bude „rozdvojen“. Metoda TOC říká, že se musí posilovat tzv. „úzké místo“. Co když jsou dvě úzká místa, která omezují projekt stejným způsobem? Uvedu příklad, který je možná jednoduchý, ale demonstruje tuto myšlenku.

Vyrábí se plastové korálky, které se poté navlečou na řetízek, předtím, než se navlečou, se musí nabarvit. Půlka korálků má být růžová a druhá půlka žlutá. Korálků na každém řetízku má být stejně. Na růžové nabarvení je potřeba stroj A, na žluté nabarvení stroj B. Za předpokladu, že máme zdroje pouze na posilnění jednoho úzkého místa (či na posilnění lichého počtu), tak se posilňování pouze jednoho úzkého místa nevyplatí.

S tímto souvisí i „cyklický proces“ zlepšování. Metoda TOC přímo říká, že se má neustále zlepšovat, to může platiti třeba u optimalizace procesů, ale v případě projektů, kde existuje nějaký deadline, bych rád věděl, kdy skončit. Projekt bude muset mít nějaký projektový plán a toho se v průběhu projektu pokud možno držet. V průběhu projektu totiž dojde k situacím, kdy se ukáže jako problém něco, s čím se třeba nepočítalo. Může jít například o to, že tiskárně tiskne pomaleji, než jak je uvedeno v její specifikaci – a hned se ukáže, že úzké místo je někde jinde, než bylo naplánováno. Otázkou tedy je, jestli na základě této skutečnosti se má v průběhu projektu přeplánovat sled úkolů. Pokud by k tomuto přeplánování docházelo častěji, tak by pracovníci na projektu si zvykali na nově nastavené procesy a celý projekt by tím prodloužil. Omezením tedy je to, že se doporučuje „neustálé zlepšování“, které v teoretické rovině určitě je prokazatelně přínosné, ale v praktické to může přinášet zmatky, které mohou vést k prodloužení a prodražení projektu.

Omezením při plánováním metodou CCPM je také odhad pracnosti, který se dává ke zpracování pracovníkům s tím, že by v něm neměly být žádné rezervy (všechny rezervy se dávají do celkových rezerv). Kdo zkontroluje, zda si tam nedali zaměstnanci rezervy i tak? Šlo by samozřejmě o skryté rezervy, které by zaměstnanci nevykazovali jako rezervy, ale jako součást práce. Projekt by se tedy mohl, oproti standardnímu plánování pomocí TOC, natáhnout ještě více a kvůli těmto „skrytým“ rezervám by se ani nepředešlo tzv. „studentského syndromu“, který je také jedním z důvodů zavedení CCPM. (Pracovníci by cítili, že mají k dispozici rezervu a práci by nechali až na poslední chvíli.)

Pokud bychom stanovili předpoklad, že pracovníci odevzdají reálný odhad své práce, tak pak se nabízí otázka, zda reálný odhad práce obsahuje i kontrolu výsledků, bez kontroly by se mohl projekt zbytečně protáhnout (otázkou je, jestli by zaměstnanci kontrolovali své výsledky, i kdyby na to čas měli).

Dle toho, co jsem se o TOC či CCPM dočetl, jsem si všiml, že se klade hlavní důraz na dokončení projektů včas. Zmínka o nákladech také někde byla, ale o kvalitně výsledného produktu, či služby, jsem se nedočetl. Každý projekt není stejný a někde je kvalita tím nejdůležitějším faktorem, proto se použití principů TOC či CCPM mělo omezovat pouze na řízení projektů, kde není kvalita na prvním místě.

U CCPM je jistým omezením i myšlenka tzv. „štafetového běžce“. Kdy má pracovník ihned po dokončení úkolu předat svůj úkol na dalšího pracovníka, který má na starost na základě vypracovaného úkolu zpracovat úkol vlastní. Tato myšlenka má hned dvě omezení. První navazuje na mou kritiku související se s tím, že podle TOC se má neustále s projektem pracovat a odstraňovat úzká místa, pokud se tedy posloupnost úkolu bude neustále měnit, tak pracovník nebude vědět, komu má vlastně úkol předat. Druhý problém je se subdodavateli. Pokud budeme outsourcovat nějakou část úkolu, tak pracovník nemusí mít kompetence k tomu, aby zadával úkoly dodavateli. A i kdyby měl, tak kdo zaručí, že se subdodavatel bude ihned věnovat svému přidělenému úkolu? A pokud ano, tak kdo zaručí, že nebude provádět tzv. „multitasking“, který by projekt snad ještě více zbrzdil, než kdyby na úkolu začali subdodavatelé pracovat o něco později? A i kdyby všechno pracovalo perfektně, tak komunikace se subdodavatelem není jako komunikace uvnitř firmy. Ve firmě, když si někdo po odevzdání své části práce (úkolu) zpětně uvědomí, že něco odevzdal špatně, tak zajde za kolego, řekne mu to a vysvětlí (pokud by si to uvědomil v nějakém rozumném časovém intervalu). V případě komunikace se subdodavatelem hrozí, že změna zadání zvýší náklady, které by po zaměstnanci mohla firma poté vymáhat. Pod tlakem této skutečnosti nebude chtít zaměstnanec sjednat nápravu a nechá subdodavateli špatné podklady.

Jaká vidíte omezení použití principů TOC a CC v řízení projektů IS/ICT? 5.00/5 (100.00%) 1 vote
Share the joy
  •  
  •  
  •  

About Václav Veselka

Jmenuji se Václav Veselka a jsem absolventem oboru "Informační systémy a technologie" na VŠE. Pracuji v internetovém marketingu. To, co dělám, mě baví, jelikož se zajímám o většinu věcí okolo webu, takže něco umím z HTML, CSS, jQuery, PHP. Rád mám fotbal a miluju Spartu.

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>