Lžete sami sobě? Pojďte se ujistit, že nikoliv

A tendenci se balamutit máme všichni – ne proto, že bychom úmyslně volili špatné priority, chybně se rozhodovali a sledovali nedůležité cíle, ale proto, že pohled skrz růžové brýle nám ukazuje věci tak, jak bychom si je přáli, nikoli tak, jaké ve skutečnosti jsou. V praxi nastávají určité běžné situace, kdy CIO klamou – ne své podřízené nebo kolegy ve vedení – ale sami sebe. Zde je devět nejčastějších.

Sebeklam CIO č. 1: Jsme sladění s byznysem

„Sladění IT s byznysem“ zní jako skvělá myšlenka a mnozí CIO zavádějí složité procesy řízení, aby ji uvedli do praxe. Smutné je, že vnitřně sladěných je jen velmi malé procento podniků. Většina připomíná spíš znesvářený klan Ewingů ze seriálu Dallas než harmonickou rodinu Partridgových ze stejnojmenného seriálu téže doby. Volí tedy systém založený na proplácení nákladů, tzv. chargeback. Ten v zásadě znamená to, že IT poskytne cokoli, o co byznys požádá, pokud je to ochotný financovat. IT možná nebude sladěné s byznysem, ale alespoň s byznysovým rozpočtem. Pokud ten odpovídá potřebám byznysu, vše je v pořádku. Pokud ne, není to chyba IT.

Sebeklam CIO č. 2: Software má cenu upgradovat pouze v případě, že nová verze má důležité výhody pro byznys

Zní to nejen přesvědčivě, ale i prozíravě. CIO, který takto argumentuje, jednoznačně uvažuje v relacích byznysu a nelze jej obvinit z toho, že by zbytečně utrácel za nové technické výstřelky. Nejen to, IT rozpočet lze snížit, protože není nutné platit za udržování softwaru na aktuálních verzích. Avšak CIO, kteří něco takového tvrdí, buď nezažili nesmírně bolestivý přechod na verzi o několik generací vyšší nebo zažili, ale vinu za všechny potíže dokázali svalit na jiné. Aktualizace softwaru představují preventivní údržbu. Buď zaplatíte dnes, nebo později, ale později jsou náklady podstatně vyšší.

Sebeklam CIO č. 3: Narůstající zpoždění klíčového projektu důležitého pro rozvoj firmy doženeme v příští fázi a hotovo bude včas

Obvykle to probíhá následovně:

Obchodní zdůvodnění: chabé. Duševní otec projektu dělá to, co dělali manažeři už za dob, kdy neexistoval Excel: upravují parametry a podmínky tak dlouho, dokud předpokládaná návratnost investice nedosáhne alespoň minimální požadované úrovně a nepřesvědčí sami sebe, že revidované předpoklady jsou, když ne úplně realistické, tak alespoň s trochou fantazie představitelné.

Požadavky a specifikace: odhadnout dobu nutnou k definování požadavků a specifikací je těžké. Tato fáze se přece protáhne u každého většího projektu, takže nač se stresovat zpožděním, vždyť čím podrobnější a kompletnější požadavky máme, tím méně času nám zabere programování a testování. Nebo ne?

Plánování: IT máme sladěné s byznysem, takže si stanovíme datum požadovaného odevzdání a sestavíme časový plán nazpátek. Tentokrát si s čísly musí pohrát projektový manažer, aby předložil alespoň zdánlivě realistický harmonogram. Ale nevadí, nikdo ho nebude detailně zkoumat, protože jim slibuje, co chtěli slyšet.

Žlutá: to je barva pro stav projektu. Znamená zpoždění bez naděje na záchranu termínu, ale dostatečně dlouho před odevzdáním na to, aby byl skutečný stav všem zřejmý. Protřelí projektoví manažeři v této fázi podniknou dva kroky: osekají testování, aby se ušetřil čas, a začnou si hledat novou práci, než jim nezdařený projekt zkazí reputaci.

Testování první úrovně: spočívá v revidování příliš vysokých nároků na to, co znamená „dostatečně dobré“. S rozvolněnými standardy a dostatkem politické podpory je možné do produkce vydat i ten nejmizernější kód.

Testování druhé úrovně: testovat se musí, a to důkladně. Otázka je, zda se důkladné testování uskutečnilo před uvolněním softwaru do produkce, nebo po něm.

Vlak vykolejil: nový CIO přichází řešit katastrofu. Jeho předchůdce obviňuje projektového manažera. Projektový manažer dochází na semináře Institutu projektového managementu jako alkoholik na skupinovou terapii.

Sebeklam CIO č. 4: Zavedli jsme ITIL

Možná se to bude zdát jako slovíčkaření, ale ITIL nelze „zavést“. ITIL je rámec, který uvádí aspekty, v nichž by mělo IT excelovat, ale nestanoví, jak toho dosáhnout. Jednotlivé položky na seznamu ITIL lze totiž provádět mnoha různými způsoby podle konkrétních okolností – stačí si představit IT v malé reklamní agentuře a IT v bance. Řada CIO si navíc ITIL představuje jako dobře fungující centrum podpory, případně ustanovení změnového výboru jako prostředníka mezi vývojáři aplikací a provozem IT.

Sebeklam CIO č. 5: Fungujeme agilně

Existují IT oddělení, která opustila kaskádový vývoj a vydala se cestou některé z agilních metodik. Avšak na každé, které skutečně přešlo na agilní přístup, připadá deset jiných, jejichž způsob práce je spíše „kaskagilní“. To znamená, že striktně dodržují formální stránku rámce Scrum a zcela ignorují ducha agilní transformace. A jinde namísto agility vládne nahodilost, často pod vedením konzervativního tradicionalisty, který vždy tvrdil, že agile nemůže fungovat – a udělal vše pro to, aby se jeho proroctví naplnilo.

Pište pro CIO Business World

Máte dobré nápady, máte co říct? Chcete se podělit o své znalosti se čtenáři CIO BW?

Je tu ideální příležitost. V redakci neustále hledáme externí autory, kteří rozšíří náš záběr. Nabízíme možnost publikací zajímavých článků nejen na webu, ale také v našem tištěném magazínu. Pokud máte zájem, ozvěte se šéfredaktorovi na e-mail: radan.dolejs@iinfo.cz

Sebeklam CIO č. 6: Praktikujeme DevOps

Určitě ne, pokud také tvrdíte, že užíváte některou agilní metodiku. DevOps a Scrum totiž nejsou z principu vzájemně kompatibilní. Kanban funguje lépe. Poznamenejme, že propagátoři DevOps nevymysleli spolupráci mezi různými složkami podnikového IT. Agilní metodiky ji prosazovaly mnohem dříve. Nutné je také mít na paměti, že vývojáři spolupracují s provozem IT z čistě utilitárních důvodů – chtějí mít své prostředí k dispozici rychle a nechtějí čekat s vydáváním změn. Navíc jim v tom všudypřítomná automatizace usnadňuje práci.

Sebeklam CIO č. 7: Pěstujeme kulturu služeb zákazníkům

Slyšíte pochechtávání z helpdesku – pardon, centra služeb? To si kolegové vyprávějí veselé historky o hloupých uživatelích. A to není rozhodně dobrý základ kultury služeb zákazníkům. Ta začíná respektem. Je běžné, že usilujeme-li o kulturu služeb klientům, bere IT zbytek podniku jako zákazníka. Což není šťastný nápad. Vede totiž k nepříliš šťastným konceptům, jako je výše zmiňovaný chargeback, který je skvělou příležitostí k plýtvání časem, energií a důvěrou při dohadování o rozpočtu na IT. Odstraníme-li však slovo „zákazníkům“, zbude pouze „kultura služeb“. A to je něco, oč by měl CIO rozhodně usilovat.

Sebeklam CIO č. 8: Naše informační bezpečnost je neprůstřelná

Často se stává, že když máme kontrolní seznam, stane se cílem snažení odškrtávání splněných položek namísto toho, aby seznam sloužil ke sledování aktuálního stavu. V IT to platí nejen u vývoje či uplatňování metodik, ale také u bezpečnosti, zejména v případě, že je nutné dodržet závazné předpisy. Vzpomeňme obchodní řetězec Target, kterému v roce 2013 unikly údaje o zhruba 40 milionech zákazníků navzdory souladu s bezpečnostním standardem PCI pro platební karty. Domnívá-li se CIO, že je zabezpečení informací dokonalé, velmi pravděpodobně se mýlí. A naopak, tam, kde CIO mají obavy z nedostatků v ochraně, může být zabezpečení velmi solidní.

Sebeklam CIO č. 9: Naše řídicí procesy zajišťují, že se IT pouští pouze do projektů s vysokým obchodním přínosem

Opět se vracíme ke sladění IT s byznysem. Účelem IT governance je zajistit, že financování získají pouze projekty s nejvyšším užitkem pro podnik. Avšak příslušný proces, bez ohledu na dokonalost jeho nastavení, implementují stejní vzájemně nesladění lidé. Ve výsledku proto kromě posouzení užitku z projektu vstupuje do hry politikaření a „jánabráchismus“.

Další důležitý aspekt: projekty, jejichž přínosem je snížení nákladů, mívají přednost před těmi, jejichž přínosem je zvýšení výnosů. Proč? Protože snížení nákladů má v rukách podnik. Když vše půjde podle plánu, náklady klesnou. Avšak zvyšování výnosů závisí na tom, že se zákazníci budou chovat podle předpokladů. Což často nedělají. Nemůžete je komandovat, musíte je přesvědčit.

A jaký z dosud řečeného vyplývá závěr? Pokud jste si čímkoli z toho příliš jisti, pravděpodobně jste na omylu. Jste-li na pozici CIO a s jistotou tvrdíte kterýkoli z uvedených devíti bodů, položte si jednoduchou otázku: proč?

Sebeklam CIO č. 10: Do téhle záležitosti nemusíme byznys zatahovat

Představme si, že by IT sestavilo kádr prvotřídních expertů na řízení vztahů, kteří by měli na starosti jednání s byznysem. Dále si představme, že dělají svoji práci spočívající v koordinaci rozvoje IT s obchodními potřebami a tak dále. Brzy se ale můžeme ocitnout v situaci, kdy by se byznys měl namísto skutečného zapojení do projektů, které se ho bytostně týkají, spokojit pouze s jednáním skrze prostředníka. Což nemusí být praktické, efektivní ani lidsky schůdné. Tam, kde IT projekt ovlivňuje nebo zcela mění zavedené podnikové procesy, je nutné, aby měli lidé z byznysu pocit, že se na výsledku skutečně podíleli, nikoli že byli postaveni před hotovou věc.