Alternativa k Asaně pro kontrolu rozpočtu projektu: šest požadavků
Problém není v tom, že by v Asaně nešlo zapsat částku. Jde to, a to hned několika způsoby. Problém je v tom, že rozpočet tam není objektem projektu, ale informací připojenou vedle, takže peníze vždy leží vedle plánu, který je vytváří. Dokud je projekt malý, rozdíl není vidět. Jakmile se začne vyúčtovávat, ukáže se, že nástroj umí zobrazit zadanou částku, ale neumí ji spočítat, prognózovat ani sladit s účetnictvím. Tento článek popisuje šest požadavků, které musí nástroj splnit, aby šlo rozpočet skutečně kontrolovat, a mechaniku, která za nimi stojí.

Klíčové poznatky:
- Zapsat částku není kontrola rozpočtu. Kontrola začíná tam, kde systém počítá odchylku, prognózuje zbývající náklady a zůstává v souladu s účetnictvím.
- Rozpočet musí dozrávat s projektem. Odhad v zakládací listině stačí ke schválení startu; detail se vyplatí tvořit až po tomto rozhodnutí.
- Rozpočtové položky patří k harmonogramu. Pokud posun úkolu neposune datum platby, je peněžní tok zastaralý ve stejném týdnu, kdy vznikl.
- Prognóza je důležitější než skutečnost. „Utratili jsme 40 %“ popisuje minulost; rozhodnutí se změní až ve chvíli, kdy víte, co ještě zbývá utratit.
- Bez účetních atributů se rozpočet projektu a knihy rozejdou. Nákladové středisko, druh výdaje a dodavatel na každém řádku drží obě strany u stejných peněz.
Kde v úkolovém nástroji končí kontrola rozpočtu
Vyplatí se jasně říct, co Asana v této oblasti umí, jinak si snadno koupíte řešení na špatně položený problém. Rozpočtovou částku můžete zapsat jako vlastní pole u projektu, přiřadit náklad k úkolu a postavit zobrazení, které tato čísla sečte. Pro tým, který chce mít po ruce řádovou představu, to někdy stačí, a srovnání FlexiProject a Asany funkce po funkci ukazuje, kde se táhne širší mezera.
Hranice je tam, kde rozpočet přestává být informací a stává se něčím, co řídíte. Kontrola rozpočtu znamená, že systém zná plán, eviduje skutečnost, přijímá prognózu zbývajících nákladů a sám počítá odchylku, přičemž každá z těchto hodnot nese datum z harmonogramu. Úkolový nástroj pod tím žádný takový objekt nemá, takže vše nad součtem se musí stavět vedle, a právě tam přestává být čtyřfázový cyklus kontroly nákladů uvnitř nástroje proveditelný.
Tři obcházení, která týmy skutečně používají
První je vlastní pole s rozpočtem a druhé s utracenou částkou. Funguje to, dokud se někdo nezeptá, z čeho se rozdíl skládá, protože pole nemá strukturu a nejde rozložit na řádky.
Druhé je tabulka vedená vedle nástroje, obvykle projektovým manažerem a někdy controllerem. Je pružná, proto je oblíbená, ale vyžaduje někoho, kdo ji ručně udrží v souladu s harmonogramem, fakturami a rozhodnutími přijatými jinde. Třetí je integrace s finančním systémem, která přinese skutečné náklady, ale ne plán ani prognózu, protože úkolový nástroj je nemá kam uložit.
Co obcházení stojí
Každé z nich funguje a každé má stejnou vadu: náklad žije odděleně od plánu, který ho způsobuje. Z toho plynou tři důsledky. Prvním je dvojí zadávání, tedy práce, která nevytváří žádnou novou informaci. Druhým je rozcházení mezi rozpočtem projektu a knihami, které se obvykle objeví na konci čtvrtletí a končí diskusí o tom, čí čísla jsou pravá.
Třetí je ten drahý: rozhodnutí na datech starých několik týdnů. Když aktualizace rozpočtu stojí úsilí, dělá se zřídka, a čím řidčeji se dělá, tím méně je spolehlivá ve chvíli, kdy je skutečně potřeba. Překročení pak není odhaleno, ale objeveno, a přesně tak dochází k překročení rozpočtů projektů i při pozorném řízení. Věnujeme se také tomu, na co se dívat, když zvažujete aplikace podobné Asaně.
Šest požadavků na kontrolu rozpočtu projektu
Odečtěte ze srovnání marketing a kontrola rozpočtu se scvrkne na šest věcí. Každá z nich je buď mechanikou v systému, nebo úkolem, který provádí člověk.
| Požadavek | Co se bez něj rozbije |
| Rozpočet se strukturou řádků | Jediné číslo neřekne, odkud odchylka pochází |
| Rozpočet, který v čase dozrává | Buď detailujete projekty, které nikdy nezačnou, nebo rozhodujete bez finančního podkladu |
| Náklady a výnosy | Vidíte výdaje, ale ne výsledek projektu, na který se ptá vedení |
| Vazba na harmonogram | Peněžní tok se rozejde při prvním posunu data |
| Plán, skutečnost a prognóza | Víte, co bylo utraceno, ale ne, zda se vejdete |
| Účetní atributy a integrace | Rozpočet projektu a knihy popisují stejné peníze dvěma různými čísly |
Dohromady popisují, co musí software pro rozpočet projektu poskytnout, než je kontrola vůbec možná. Zbytek článku prochází požadavky po pořadě a ukazuje, jak je každý řešen ve FlexiProject.
Zažijte řízení projektů na nové úrovni s pokročilým PPM softwarem, začněte zdarma ještě dnes.

Rozpočet, který dozrává s projektem
Obvyklý konflikt na začátku vypadá takto: schválení projektu vyžaduje finanční podklad a spolehlivý rozpočet vyžaduje práci, která přijde vniveč, pokud je odpověď ne. Většina organizací to plete jedním ze dvou směrů, buď rozhoduje bez čísel, nebo tvoří detailní plány pro věci, které nikdy nezačnou.

Modul zakládací listiny projektu může nést odhadovaný rozpočet na úrovni hlavních řádků, například služební cesty za dvě stě tisíc, a to stačí k rozhodnutí. Teprve po schválení listiny, během plánování, projektový manažer tyto řádky rozloží na tuzemské cesty, zahraniční cesty, externí dopravu a vlastní dopravu. Detail se objeví tam, kde se začne vyplácet, a ne dříve, než kdokoli ví, zda bude potřeba, což je i logika za tvorbou a kontrolou rozpočtu během realizace.
Dvouúrovňový rozpočet u milníků fáze
Ve výzkumných a investičních projektech se stejný problém vrací v každé fázi, protože pozdější fáze prostě nejdou nacenit dopředu. FlexiProject pro tento případ podporuje dvouúrovňový rozpočet: aktuální fáze má detailní plán s konkrétními řádky, zatímco zbývající fáze nesou odhad podle toho, co je známo na začátku.
U každé brány projektový manažer vytvoří detailní rozpočet pro následující fázi a opraví odhady pro zbytek na základě toho, co ho aktuální fáze naučila. Řídicí výbor schvaluje výdaje pouze v rámci následující fáze, což je smysl bran: peníze se uvolňují po částech, ne jedním podpisem na začátku. Postupné verze rozpočtu se archivují, takže o rok později je vidět, jak a proč se předpoklady změnily.
Náklady, výnosy a výsledek projektu
Většina nástrojů chápe rozpočet projektu jako stranu výdajů, což stačí jen tehdy, když projekt nic neprodukuje. V komerčních projektech, zákaznických implementacích, iniciativách výzkumu a vývoje s očekávanou návratností nebo investicích s modelem návratnosti není otázkou, co bylo utraceno, ale co projekt vydělá.
FlexiProject staví rozpočet z obou stran, nákladů i výnosů, s řádky seskupenými tak, jak organizace potřebuje. U projektů generujících výnos systém ukazuje plánovaný zisk, odchylku oproti plánu a prognózu konečného finančního výsledku. To je číslo, na které se vedení ptá, a nelze ho odvodit jen ze součtu nákladů, protože posun data akceptace mění obě strany rovnice najednou.
Rozpočtové položky svázané s harmonogramem
Zde se většina finančních a většina projektových nástrojů rozchází nejvíc. Rozpočty se obvykle berou jako samostatný modul, zatímco ve skutečnosti jsou nákladové řádky těsně provázané s daty úkolů. Záloha dodavateli odchází při objednávce, konečná platba po akceptaci, mzdový náklad během instalace.
Ve FlexiProject lze rozpočtové položky dynamicky navázat na úkoly v modulu harmonogramu projektu. Když se změní datum úkolu, aktualizuje se s ním i datum příslušné rozpočtové položky, takže peněžní tok projektu vždy odráží aktuální plán bez ruční synchronizace. Praktický rozdíl je prostý: bez této vazby každá změna harmonogramu tiše zneplatní prognózu peněžního toku a nikdo si toho nevšimne, dokud peníze nechybí v měsíci, kdy tam měly být.
Fotovoltaický projekt to ukazuje jasně. Řádky jako panely, měniče, konstrukce, práce a projekce jsou navázané na konkrétní úkoly, systém přepočítá součet při změně cen nebo množství a faktury subdodavatelů dopadají na správné řádky automaticky. Odchylka oproti plánu je vidět průběžně, ne až na konci fáze. Odděleně vysvětlujeme, jak zvládnout plánování projektů, které si systém udržuje sám.
Plán, skutečnost a prognóza do dokončení
Kontrola rozpočtu potřebuje tři hodnoty, ne dvě. Většina nástrojů zná plán a skutečnost, takže odpovídá jen na otázky o minulosti.
Proč je „kolik jsme utratili“ otázka o minulosti
Skutečnost popisuje peníze, které už jsou pryč. Když ukáže problém, zbývá málo možností, protože náklad už byl vynaložen. FlexiProject umožňuje evidovat skutečné výdaje a zároveň udržovat prognózu zbývajících nákladů, takže projektový manažer vidí tři hodnoty najednou: plán, co bylo utraceno a prognózu do dokončení, spolu s výslednou odchylkou.
EAC a ETC a o čem sponzor vlastně rozhoduje
Na tomto základě systém ukazuje konečnou prognózu. Obě se odvozují z indexu výkonnosti nákladů (CPI): EAC odpovídá, kolik projekt nakonec bude stát při současném tempu utrácení, a ETC, kolik ještě bude třeba utratit. Obě obvykle váží víc než odchylky, které už nastaly.
Rozdíl v praxi je značný. Sponzor, který slyší, že rozpočet byl překročen o pět procent, dostává status. Sponzor, který vidí, že prognóza při dokončení je překročení o osmnáct procent, dostává podklad pro rozhodnutí a stále má čas ho udělat: zúžit rozsah, přidat zdroje, posunout datum nebo eskalovat. Rozhodnutí přijaté včas bývá levnější než stejné rozhodnutí přijaté těsně před koncem. Ukazujeme rovněž, jak v praxi vypadá řízení rizik projektu.
Posuňte své portfolio projektů dál s výkonným PPM softwarem, 30 dní zdarma.

Účetní atributy a reporty pro finance
Rozpočet projektu, který nejde sladit s knihami, se nakonec přestane používat, protože v každém sporu o čísla vyhrává účetnictví. Proto může každý rozpočtový řádek ve FlexiProject nést atributy, které finance potřebují: nákladové středisko, druh výdaje, kategorii nákladu a dodavatele. Faktury a objednávky lze připojit k příslušnému řádku.
Druhým prvkem je integrace. FlexiProject stahuje faktury navázané na projekt z účetního systému spolu s jejich atributy, datem, částkou, číslem dokladu a dodavatelem a propojuje je se správným rozpočtovým řádkem. Projektový manažer může jeden náklad rozdělit mezi několik řádků a vazba na doklad zůstává v systému. Přepisování stejných dat na dvou místech mizí a s ním i nejčastější zdroj rozcházení.
Třetím je reporting. Finance málokdy potřebují standardní zobrazení rozpočtu projektu a častěji chtějí vlastní řez: podle kategorie, podle dodavatele, podle období, s odchylkami a prognózami. Takové reporty se navrhnou jednou a pak zůstávají dostupné s aktuálními daty, exportovatelné do Excelu pro každého, kdo chce s čísly pracovat dál. Projektový manažer přestává být prostředníkem v dodávání čísel. Samostatně popisujeme, čím musí být alternativa k Asaně pro PMO.
Schválený rozpočet a formální změna
Vše výše funguje jen tehdy, existuje-li referenční bod. Rozpočet, který se mění spolu s realitou, vždy sedí a nikdy nic neřekne. Proto se v systému pro řízení projektů FlexiProject schválený rozpočet zmrazí jako základní plán a systém hlásí odchylku mezi závazkem a aktuálním stavem.
Změny zůstávají možné, ale jsou to změny. Významnou korekci rozpočtu lze podat jako žádost s obchodním zdůvodněním a projde schvalovací cestou, po schválení se stává novou verzí plánu. Žádosti se archivují, takže po uzavření projektu lze zpětně sestavit, kdy rozpočet rostl a proč. Bez toho se diskuse o překročení scvrkne na otázku, vůči čemu přesně se to vlastně měří.
Kdy je tohle víc, než váš projekt potřebuje
Pokud vedete hrstku projektů bez formálního rozpočtu, bez závazků vůči klientům a bez finančního oddělení na druhé straně, výše popsaná mechanika přidá práci, ale ne kontrolu. Vlastní pole s číslem stačí a změna nástroje by řešila problém, který nemáte.
Jiná situace je tam, kde celý model stojí na účtovatelných hodinách a fakturaci klientům. To je samostatná třída potřeb, blíž agenturním systémům než řízení rozpočtu záměru, a přehled softwaru pro řízení nákladů projektu postaveného kolem sazeb a ziskovosti zakázek je tím správným místem, kde začít. FlexiProject je nejsilnější tam, kde se rozpočet skládá z nákladových a výnosových řádků, ovlivňuje investiční rozhodnutí a musí souhlasit s knihami.
Jak to za dva týdny vyzkoušet na vlastním rozpočtu
Srovnání funkcí rozhodne málo, protože stránka každého dodavatele odpovídá na vše ano. Vezměte jeden běžící projekt se skutečným rozpočtem a postavte ho znovu: strukturu řádků, plánované částky, dosavadní výdaje. Už tento krok ukáže, zda vám struktura rozpočtu, kterou používáte, do nástroje sedne, aniž byste ji museli ohýbat.
Pak čtyři testy. Posuňte úkol v harmonogramu o dva týdny a ověřte, zda se s ním posunulo i datum navázaného rozpočtového řádku. Zadejte prognózu zbývajících nákladů a podívejte se, zda se odchylka a prognóza při dokončení spočítaly samy. Stáhněte fakturu z účetního systému a zkontrolujte, že dopadne na správný řádek s úplnou sadou atributů. Navrhněte jeden report ve formátu, který finance obvykle žádají. Nástroj, který projde těmito čtyřmi, zvládne i zbytek.
Často kladené otázky
Umožňuje Asana kontrolovat rozpočet projektu?
Jen v omezené míře. Rozpočet tam není součástí modelu projektu, takže se částky evidují ve vlastních polích, v doplňku nebo v samostatném nástroji. To stačí k zaznamenání řádové představy, ale ne k výpočtu odchylky, prognóze zbývajících nákladů nebo sladění čísel s účetnictvím.
Jaký je rozdíl mezi sledováním nákladů a kontrolou rozpočtu?
Sledování nákladů odpovídá, kolik bylo utraceno. Kontrola rozpočtu navíc vyžaduje plán se strukturou řádků, prognózu zbývajících nákladů a spočtenou odchylku, s daty z harmonogramu. Praktickým testem je, zda vám systém řekne, že projekt míří k překročení, dříve než k němu dojde.
Co přináší navázání rozpočtových položek na harmonogram?
Udržuje peněžní tok aktuální. Když se posune datum úkolu, posune se s ním i datum navázané platby, takže prognóza odráží platný plán bez ruční opravy. Bez této vazby každá změna harmonogramu tiše zneplatní prognózu.
Lze rozpočet projektu sladit s účetním systémem?
Ano, pokud rozpočtové řádky nesou atributy, které účetnictví potřebuje: nákladové středisko, druh výdaje, kategorii a dodavatele. Ve FlexiProject lze faktury navázané na projekt automaticky stáhnout a připojit ke správným řádkům, což odstraňuje dvojí zadávání.
Je samotný rozpočet dobrým důvodem ke změně nástroje?
Málokdy jde jen o rozpočet. Pokud se náklady vedou v tabulce vedle nástroje, obvykle je to proto, že v téže tabulce je i harmonogram nebo prognóza, což znamená, že nástroj nedrží plán jako celek. Rozpočet ale může být důvodem dostatečným, když se projekt vyúčtovává vedení nebo dotační instituci.
Alternativa k Asaně se v tomto případě nehledá proto, že by byl nástroj špatný, ale proto, že rozpočet narazil na hranici svého datového modelu. Zapsat číslo a kontrolovat rozpočet jsou různé věci a rozdíl se ukáže přesně tam, kde je nejdražší: u otázky, zda se projekt vejde do plánu. Šest požadavků výše se scvrkává do jedné myšlenky. Peníze mají žít na stejném místě jako plán, který je vytváří, mít strukturu řádků, dozrávat s projektem, pokrývat kromě nákladů i výnosy, přijímat prognózu a souhlasit s knihami. Pokud rozpočet projektu ve vaší organizaci žije v tabulce vedle nástroje, nejlevnějším způsobem, jak zjistit, zda to stojí za změnu, je postavit znovu jeden skutečný projekt a posunout v něm jeden úkol.



