Business case je základ

Nejsem příznivcem anglikanismů, čeština je krásný a bohatý jazyk. Některé cizojazyčné výrazy jsou však přeci jen zažité, a hlavně významově přesnější. Obchodní případ je původnímu významu dosti vzdálen, byznys případ zase nic neříkající patvar. Česky proto obvykle hovořím o záměru projektu, mám však na mysli business case.

Každý projekt by měl dávat smysl z hlediska investice a navrácené přidané hodnoty. I v případě, že je projekt realizován na základě například legislativního podnětu, je přidanou hodnotou, že mohu dále provozovat svou činnost, a i v tomto případě by měl být poměr mezi investicí a přidanou hodnotou co nejlepší. Ryze obchodní vztah je v tomto případě tím nejjednodušším. Prodám řešení za X peněz, náklady jsou Y, vydělám Z.

Každý obchodní vztah začíná u zákazníka. Vedl jsem nedávno diskusi s jedním IT manažerem výrobní firmy, který chtěl inovovat informační systém ve výrobě. Aktuální stav představovalo několik různých systémů bez vzájemné provázanosti. V dnešní době v podstatě neudržitelný stav. Situoval jsem se do role majitele společnosti a vyzval dotyčného, ať mi přednese svůj záměr projektu.

„Chceme pořídit nový informační systém do výroby…,“ začal dotyčný.
„Aha, a proč?“ zeptal jsem se.
„Budeme mít jednotnou databázi a data v celé výrobě!“ rozzářil se IT manažer.
„Hmm… a co nás to bude stát?“ odvětil jsem.
„Našli jsme dobrého dodavatele, takže jen patnáct milionů…,“ zněla odpověď.
„Patnáct milionů… hmm, já těm vašim databázím moc nerozumím. Kolik nám to vydělá peněz?“ byla má další otázka.
„?!... to se takhle nedá říct…“
„Takže vy po mně chcete patnáct milionů a nejste mi schopen říct, kdy se tato investice, pokud vůbec, vrátí? Tak přijďte, až to budete vědět!“

A rozhovor byl pochopitelně u konce. Je zřejmé, že případnou návratnost investice není zcela triviální vyčíslit. Budou sem patřit záležitosti jako zkrácení času při zadávání a dohledávání informací, méně chyb, levnější údržba systému a další přínosy, které ve své podstatě budou znamenat úspory oproti současnému stavu. Takže by se snad šlo dopočítat, že zavedením nového informačního systému jsme schopni uspořit deset milionů ročně… a už je to jiná diskuse.

Otázkou je pak samozřejmě následná práce s přínosy. To, že jsme něčeho schopni, ještě neznamená, že to uděláme. Klíčem je kvantifikace, měřitelnost a zodpovědnost. Přínos definovaný jako „úspora času“ je k ničemu. Lépe zní „deset lidí ušetří hodinu týdně“. To je za týden sto hodin, za měsíc čtyři sta hodin, tedy padesát člověkodnů, tedy přibližně 1,25 pracovníka, který bude uspořen. A co bude dál? Kdo bude zodpovědný za využití takové úspory? Setkal jsem se ve více organizacích se stavem, že nic a nikdo. Ovšem pak již neplatí výše uvedené ospravedlnění investice! Nasype se patnáct milionů a …nic. Vždy by tedy mělo být zřejmé, kdo je zodpovědný za naplnění daného potenciálu a sledovat, jestli se tak děje. Správně popsaný business case tedy obsahuje nejen obě strany dané rovnice, ale rovněž klíčové zodpovědnosti v celém vztahu. Vhodným dokumentem je například identifikační listina.

Logický rámec

Logický rámec pomáhá určit základní strategii projektu – formulaci dlouhodobých přínosů, cíle projektu, výstupů, aktivit a hlavních předpokladů úspěšnosti projektu. Obvyklou podobu ukazuje tabulka.

Řádek záměru by měl obsahovat přínosy realizace projektu a zodpovědět otázku, proč vlastně projekt realizovat. Přínosů může být i více, obvykle půjde o mix finančních a nefinančních benefitů. Ke každému bodu na této úrovni je následně stanoven kvantifikovaný ukazatel dosažení daného přínosu a způsob ověření, že jej bylo dosaženo. Například by mohlo jít o snížení nákladů na provoz v celé firmě o 25 procent. Ukazatele jsou v tomto případě zřejmé.
Cíl je popis stavu v okamžiku ukončení projektu. Jakou potřebu zadavatele projektu máme naplnit? Jaký má být stav řešené problematiky na konci projektu? Cíl je předmětem dohody mezi zadavatelem zodpovědným za přínosy a manažerem projektu zodpovědným za dodání daného stavu. Přitom cíl nemusí nutně vést k přínosům stylem jestliže–pak, ale je obvykle spíše jedním z dílů skládanky, která nakonec přínosy doručí (tedy více projektů nebo i dalších akcí). V našem případě by tedy mohlo jít o cíl: „V rámci výroby je do konce roku X nasazen pouze jeden, efektivní informační systém, přičemž náklady nepřekročily patnáct milionů.“

Jak poznáme, že máme jeden systém, asi není tak složité, stejně jako ověřit termín a rozpočet, ale jak definovat, že má být efektivní? Zde jsou na řadě ukazatele typu doba odezvy, počet výpadků, doba vyhledání informace atp. Zde se domluví projektový manažer a zadavatel na kritériích úspěchu daného projektu.

Na tomto řádku také přibývá další políčko – předpoklady. Je zde na místě. Otázka „za jakých předpokladů bude jednotný informační systém ve výrobě v souladu se záměrem úspory nákladů“ je velmi relevantní. Odpovědí by mohly být předpoklady, že náklady na provoz a údržbu nepřekročí určitou částku apod. – zvolené řešení pak musí být v souladu s těmito předpoklady a jedná se o upřesnění zadání. Pokud tedy management organizace za půl roku nechá systém zásadně přepracovat, již nelze očekávat splnění základního vztahu, neboť náklady budou zřejmě vysoké. Což už ovšem není zodpovědnost projektového manažera, ale spíše osoby zodpovědné za dosažení přínosů.

Jako předpoklady jsou v logickém rámci vnímány faktory a vlivy mimo projektový tým, z tohoto úhlu pohledu vnější vlivy.

V další části logického rámce jsou definovány výstupy, jako způsob dosažení cíle. Bude pořízen krabicový software? Nebo půjde o vývoj na míru? Co hardware? Vždy asi bude potřeba provést analýzu, implementaci zvoleného řešení, pilotní provoz, školení apod.  A samozřejmě je opět relevantní se zeptat, za jakých předpokladů tyto výstupy opravdu povedou k cíli. Například je asi validní předpokládat, že nedojde k zásadním změnám ve výrobě a výrobním programu. Pokud ano, nelze po projektovém manažerovi chtít dodržení trojimperativu. Formulováním těchto předpokladů se v podstatě projektový manažer a zadavatel domlouvají na okolnostech vyloučení zodpovědnosti projektového manažera za cíl splněný ve všech parametrech (a nesplnění předpokladu bude zřejmě impulz pro změnové řízení).

Poslední řádek, aktivity, naznačují, jak by mola proběhnout realizace příslušného výstupu. Nejde o kompletní výčet, ale spíše o naznačení hlavních skupin činností. Ohledně implementace by se zřejmě dalo hovořit o činnostech jako zálohování, instalace do prostředí, migrace dat, migrace uživatelů, testování apod. Na řádku aktivit dochází k určité nepravidelnosti, místo ukazatelů a způsobu jejich ověření jsou zde odhadovány náklady na danou souhrnnou činnost a také její časová náročnost. V samotném závěru je prostor pro identifikaci předběžných předpokladů, pokud takové jsou (například dokončení nějakého předchozího projektu, uvolnění finančních zdrojů, přiznaná dotace apod.).

Velmi zajímavým políčkem je „projektem nebude řešeno“. Zde je to pravé místo pro upřesnění toho, co nebude součástí projektu, primárně je vhodné zmínit záležitosti, které by mohly být předmětem budoucích sporů. V našem případě by zde třeba mohlo být, že síťová infrastruktura není součástí tohoto projektu (a následně by se asi objevilo v předpokladech na řádku činností, že předpokládáme, že aktuální síťová infrastruktura je v pořádku, nebo bude adekvátně upravena).

Příště: Projekt máme vymyšlen, bude-li nám schválen vedením, spustíme jej.

Jan Doležal

Autor je ředitelem společnosti PM Consulting. Je držitelem certifikací PMI PMP a IPMA level B. Zabývá se především optimalizací systémů řízení projektů v různých firmách a organizacích.