Projekt nebo zakázka

18. 11. 2024 Petr Opletal

V jakých podmínkách je účelné řídit zakázky, kterým říkáme projekt, jako skutečný projekt. Čím se bude lišit systém/proces projektového řízení a proces odbavování zakázek.

Projekt nebo zakázka

Může se zdát, že jde pouze o pár pojmů. Mohlo by být jedno, jak čemu říkáme. No... úplně jedno to není + je rozumné si ujasnit, o co fakticky jde, bez ohledu na to, jak tomu budeme říkat.

Projekt

Systém/proces pro správu projektového portfolia. Sada velmi významných jedinečných aktivit. Každý projekt vychází z projektového záměru, který lze namapovat na strategický cíl (popř. více).

  • Projekt se snažíme izolovat od rutinního provozu. Je důležitý, má prioritu. Chráníme jej.
  • Není fixně dáno, co má být výstupem. V průběhu se může změnit jak záměr, tak projekt. 
  • Vyznačuje se vysokou nejistotou (postupy, náročnost, výstupy, ...).
  • Je obtížné sjednat akceptační kritéria - mj. se jimi vyjasňuje, co si zadavatel představuje (zda je to realistické) a k čemu to má být dobré.
  • Řídí jej vedoucí projektu. Nezávisle. Samostatně. Zodpovídá za průběh a výstupy.
  • Alokování kapacit probíhá vyjednáváním (popř. se relativně komplikovaně uvolňují přerozdělením již zadané práce). Pracnost úkolu nelze nařídit, trvání také ne. Určuje si to realizátor (viz koncepce stimulace Termíny a lhůty). Optimalizuje se na nejrychlejší možné dokončení (tedy předávání práce).
  • Projekt znamená pouze náklady.
  • Zadavatel přebírá výstupy a využije je k realizaci (nejistého) záměru (ten možná přinese užitek).

Zakázka

Opakující se instance běžnéh podnikového procesu. Víme, co děláme.

  • Podstata rutinního provozu.
  • Pravděpodobně není (neměla by být) součástí "obchodní části" obchodního případu (dle prostředí, preferencí zákazníků, způsobilosti lidí). 
    Obchodník se znalostí vytížení kapacit a stavu rezerv může nabídnout / přistoupit na rychlejší realizaci za vyšší cenu, ve smluvním termínu vždy musí být normativní rezerva (metodika nabídkové kalkulace dle kapacit jindy/jinde).
  • Měly by být sjednávány a práce na nich plánována tak, aby při realizaci nezáleželo na jejich "prioritě" (dané bonitou zákazníka, popř. obchodním významem dané realizace). Aneb:
    • Je víceméně známo, co se má zákazníkovi předat. Typově a obsahově se zakázky bezpochyby liší (řeší parametrizace). Je to "denní chleba", umíme to.
    • Běžná míra nejistoty. Normativy.
    • Jasný termín a cena. Ekonomická efektivnost daná obchodní politikou.
    • Lhůtu sjednáváme se zákazníkem s cílem optimalizovat využití kapacit včetně cenové stimulace (vyšší cena pro rychlé plnění, nižší pro delší lhůty).
    • Pokud se nic nerozbije, proběhne práce na zakázce dle rozpisu (plánu výroby).
  • Spotřeba/alokace kapacit je dána typem & rozsahem zakázky normativně. Optimalizujeme předávání/přidělování práce spíše s cílem minimalizovat prostoje, popř. udržovat vyhovující pravděpodobnost dokončení v termínu. Práci nařizujeme a případně následně řešíme příčiny neshod.

Přestože to na první pohled může vypadat jako projekt, není to projekt. Neměli bychom se snažit to tak řídit (i kdybychom to uměli). Výjimkou mohou být skutečně komplexní jedinečné zakázky (viz Teams pro zakázky).

Projekt × instance procesu

Čím se od sebe liší:

  • Projekt se ze své podstaty bude odchylovat od původní představy.
    • Plán práce vzniká převážně dle interpretace zadání, odhadu možností - i když bude vycházet ze šablony, bude jedinečný.
    • Odchylky se snažíme využít. Není nutné se vracet na předpokládaný průběh. Optimální postup hledáme i v průběhu projektu.
    • Úkoly členů projektového týmu jsou určovány plánem práce. Jejich trvání i vystupy se s realizátory sjednávají.
    • Nákladový limit projektu je něco úplně jiného, než (vnitropodniková) cena zakázky.
  • Zakázka
    • Naprosto zásadně jiný způsob plánování práce. Posloupnost prací je dána definovanými činnostmi (bloky, popř. konfigurovanými na základě parametrů zakázky). Všechny "použité" činnosti jsou obsaženy v katalogu činností (i kdybychom tam některou přidali teprve kvůli aktuální zakázce).
    • Odchylky se snažíme minimalizovat / kompenzovat / eliminovat. Předpokládáme, že (parametrizovaná) standardní posloupnost činností je pro dosažení stanoveného (typového) výstupu optimální.
    • Práce je spíše normována (s možností eskalace výjimky). Což nelze chápat tak, že se nemá konkretizovat dle konkrétních parametrů zakázky.
    • Zakázka se nejdřív kalkuluje (v rámci obchodní části jednání se parametricky určí pravděpodobné složky plnění a jejich náročnost, na tomto základě vzniká nabídková cena a lhůta) a po objednání se "zadává do výroby".
      Čímž není řečeno, že nikdy nemůže dojít ke změnám - zcela jistě občas bude něco cekem výrazně jinak, než se domluvilo. Jenže vzhledem k existenci smlouvy/objednávky se vlastně zakázka musí "resetovat" a sjednat znovu.

Pokud bychom činnosti zakázky znázornili obdobným způsobem, jako plán prací projektu (např. Gantt-úv diagram), tak bude vypadat naprosto stejně jako projekt. To neznamená, že bychom se té instanci procesu měli chovat jako k projektu. Významný rozdíl je v hospodaření s kapacitami (což je příliš obsáhlé téma, není účelné ho zde otevírat). Souvisí s rolemi / způsobem řízení.

Koordinátor provozu (zakázek)

Nemá to být "vlastník procesu". Je to částečně "rutinní" člověk, který (pouze) koordinuje instance procesů, které má na starosti (co znamená "koordinuje" jinde/jindy, resp. záleží na konkrétních podmínkách - podobě "jeho" povinností aneb konkrétním procesním modelu).

  • Jasné pracovní povinnosti (zajistit dostupnost zdrojů, vyhodnotit úroveň plnění povinností lidí pracujících na zakázkách, ...).
  • Relativně jednoduché činnosti (dané procesním modelem).
  • Musí řešit výjimky (neshody) - nejdřív opatření vedoucí k minimalizaci škod. Přivolá k havárii vlastníka procesu (pokud je k dispozici, jinak o nouzovém řešení rozhodne sám) a společně hledají optimální bezprostřední reakci (pokud je to ještě účelné). Za korekci / doplnění procesu zodpovídá vlastník.
  • Plán / řízení produkce je plně algoritmické (není myšleno "automatické", ale definované jednoznačnými pravidly).

Projektový manažer

Pokud má skutečně řídit skutečné projekty, tak je to velmi kvalifikovaný a velmi samostatný řídící pracovník. Není vlastníkem procesu projektového řízení, ale je "vlastníkem" toho projektu. 

  • Sám a výhradně určuje podobu/průběh - vytváří (v součinnosti s projektovým týmem, což jsou opět velmi samostatní specialisté, které si vybírá pro dosažení těch výstupů, které má za úkol projektem doručit) plán prací, zajišťuje jeho systematickou aktualizaci a rozhoduje o jeho přizpůsobování měnící se úrovni poznání (vývoji všeho). 
  • Plán prací sice může vycházet z některé šablony, ale u skutečných projektů budou případné kroky většinou natolik rámcové/obecné, že je nutno jej iterativně upřesňovat. Mimo jiné také dle aktuálně/předběžně dostupných zdrojů.
  • Samostatně a iniciativně vyhodnocuje potenciální hrozby a nejistoty, hledá/ověřuje a provádí změny (opatření), která snižují pravděpodobnost neúspěchu. 

Asi by tyto rozdíly měly stačit.

Možná stojí zato probrat rozdíly v předcházejících aktivitách - obchodní jednání u zakázek versus sjednávání strategických cílů u projektů / záměrů.

Pokud máte dotazy či doplnění, ozvěte se nebo se zapojte do diskuse na LinkedIn.