Počítali jste někdy odhad IT nákladů pro product pitch na řešení, se kterým v dané podobě nemá nikdo ve firmě přímou zkušenost? Zejména v ideační fázi, kdy je mnoho věcí nejasných, se hlavní úsilí soustředí na stanovení přibližné úrovně nákladů. Podle komunikační potřeby se do těchto čísel přidává i nějaké konkrétní, ideálně nezaokrouhlené číslo, aby výsledek působil důvěryhodněji a vědečtěji pro sponzora. Takto vzniklé číslo se pak použije pro rozhodovací proces nebo stanovení finančního rámce. Abychom se vyhnuli faux pas, nebudeme se zde zabývat opačnou stranou rovnice, tedy formulací očekávaných výnosů.

Během samotného vývoje, ať už v rámci designu nebo při práci vývojářů, často dochází k významným změnám. Objevují se dodatečné integrace, které původně nebyly plánovány, ale stávají se nezbytnými po zpřesnění zadání. V moderních metodikách vývoje analýza i design pokračují souběžně s vývojem, což vede k činorodé výměně názorů a kompromisů. Pokud návrh kompromisu není schválen, následují naléhavé schůzky s product ownery dotčených aplikací. Jejich výsledkem často bývá postoj "ono se to tam vejde", což v danou chvíli situaci formálně řeší, ale reálně se na náklady zapomíná. Zvýšené náklady se přelijí do jiného budgetu, a pokud má někdo rezervy nebo počítá s růstem v rámci business as usual, věří se, že se někde ztratí. Nejčastější obětí jsou oddělení, která nejsou přímo spjata s business funkcionalitou, a jsou tedy v náhledu firmy pouhým nákladem.

Pokud vše dopadne dobře, aplikace je nasazena do pilotního provozu a následně do produkce. DevOps tým či product owner dostane jednou za kvartál nebo i ročně výstup z interního rozúčtování on-premises komponent. Pokud se používá cloud, je denně k dispozici detailní billing. Ovšem s odstupem času se již většinou nikdo nezabývá skutečnými náklady na celkovou business službu nebo produkt. Většinou se sledují pouze náklady konkrétní aplikační infrastruktury, která se dá prezentovat zjednodušeným modelem. Sledovat reálné náklady je složité, sdílené služby nejsou dostatečně rozlišené a často zatěžují týmy, které není business schopen identifikovat jako užitečné.

Business tak často zjistí, že si objednal něco jiného, než dostal, a zaplatil za něco, co původně nechtěl. Ale vlastně ne tak docela – protože většinou nemá přesné informace o tom, co jeho požadavek skutečně stál. Modely nákladů se různě liší a jejich přesnost závisí na důslednosti DevOps týmů a schopnosti sdílených služeb efektivně komunikovat. A jak asi tušíte, většinou komunikovat neumějí. To vede k dojmu, že IT provoz je čím dál dražší a netransparentní. V reakci na to se business snaží implementovat SaaS řešení, která IT obcházejí – ale paradoxně se IT nakonec vrátí přes identitní služby, integrace a data.

Část nedůvěry v IT pramení z toho, že nepracuje na servisně orientovaném přístupu. Každá business služba by měla mít transparentně stanovenou cenu a billing, ale tradiční přístup IT soustředěný na celkové náklady už nestačí. Moderní enterprise architektura rozděluje business funkce a data, což přináší větší přehlednost a flexibilitu, ale komplikuje billing. Skutečně užitečné FinOps metriky si proto musí každá organizace definovat sama.

Aby IT zůstalo partnerem businessu, musí transparentně komunikovat náklady a spoluvytvářet varianty rozvoje. Vestavěné sledování billable metrik pomůže propojit náklady s produkty a službami, i když to vyžaduje změnu firemní kultury. Pak možná bude "zpětné vyhodnocení business case" vyvolávat méně nervózního smíchu. Držme si palce.