Мениджмънт

10 лъжи, с които главните информационни директори заблуждават себе си

CIO Media

Боб Люис, CIO, САЩ

Ако Ахил беше главен информационен директор, самозаблудата щеше да е неговата пета. Той щеше да е сигурен, че синхронът между бизнес и ИТ е точен, информационната сигурност е непробиваема и всички проекти се изпълняват навреме. Лъжейки самите себе си, CIO-тата подготвят сцената за бедствие.

Ситуацията силно напомня на един цитат от шотландския романист Уолтър Скот: "Каква заплетена мрежа изтъкахме, когато започнахме да мамим." Но независимо колко заплетена е мрежата, когато някой друг е мишената, бъркотията не е толкова голяма, както когато заблуждаваме самите себе си. А ние правим точно това и не защото искаме умишлено да поставим грешните приоритети и да преследваме грешните цели, а защото самозалъгването е много по-лесно, отколкото да гледаме света през розови очила.

Тук са описани десет често срещани ситуации, когато главните информационни директори лъжат, но не своя ИТ персонал или колегите си, а себе си.

Самозаблуда №1 на CIO: Ние сме в съответствие с бизнеса.

"Съответствието на ИТ с бизнеса" звучи като нещо страхотно, което трябва да се направи. Затова и CIO-тата започват сложни процеси за ИТ управление, за да се уверят, че това се случва. За съжаление малко бизнеси от всякакъв размер са в синхрон със себе си. Съответствието с бизнеса обикновено се свежда или до помиряване на силните политически играчи, или до въвеждане на система за връщане на средства.

Какво означава "връщане на средства"? Това е превръщане на ИТ отдела в нещо като момче за всичко: Ние ще ви дадем каквото поискате, стига да финансирате проекта. С връщането на средства ИТ може да не е в съответствие с бизнеса, но е в съответствие с бюджета. Ако това е в съответствие с бизнеса, всичко е наред, ако не, ами това е нечий друг проблем.

Самозаблуда №2 на CIO: Единствената причина за надграждане на софтуера е, когато новата версия носи важна стойност за бизнеса.

Това звучи не само убедително, но и управленско. Информационен директор с подобно мнение е ясно фокусиран върху бизнеса (и в съответствие с него) и не може да бъде обвинен в изразходване на средства за технология заради самата технология. Още по-добре, ИТ бюджетът може да се свие, тъй като не трябва да покрива разходите за поддържане на нещата актуални. CIO-тата, които са на това мнение обаче, или никога не се преживявали катастрофален ъпгрейд след пропускане на няколко технологични поколения, или са успели да прехвърлят вината за бъркотията.

Софтуерните надстройки са превантивна поддръжка. Може да се платят сега или по-късно. По-късно обаче струва доста по-скъпо.

Самозаблуда №3 на CIO: Големият, критично важен проект, който изостава от графика? Ние ще наваксаме в следващата фаза и ще го предадем навреме.

Ето обичайното развитие:
Бизнес случаят: Авторите на начинаещото бедствие правят това, което мениджърите са правили преди появата на електронните таблици: въртят и сучат, докато възвращаемостта на инвестицията надвиши минималната стойност, убеждавайки себе си, че коригираните допускания са все още ако не напълно разумни, то поне изпълними с известен късмет и силен попътен вятър.

Изисквания и спецификации: Фазата на приблизително оценяване на изискванията и спецификациите е трън в петата. Колкото по-голям е проектът, толкова повече неизвестности крие, като всяка от тях усложнява още повече нещата. Фазата на приблизително оценяване винаги е продължителна, но това е добре. Всеки знае, че колкото повече време отделите за проектиране, толкова по-малко време ще ви отнеме писането на код и тестването. Тогава ще го измислим.

Планиране: ИТ са в съответствие с бизнеса и всичко, планирането върви от дясно наляво, като започва с датата на предаване и работи назад до графика, който ще го постигне. Този път ръководителят на проекта е човекът, който отчаяно се върти и усуква до момента, в който графикът започне да изглежда правдоподобен. Докато никой не го погледне твърде отблизо. Което те няма да направят, тъй като им се казва това, което искат да чуят.
Жълто: Това е статусът на проекта, известен още като изоставане от графика без път за спасяване, но достатъчно време преди крайния срок, когато отричането все още замества реалността. Находчивите ръководители на проекти предприемат две действия, когато даден проект достигне този етап. Първо, съкращават тестването. Това поставя проекта в зелената зона. Второ, започват търсене на работа.

Тестване на ниво едно: Това се състои в предефиниране на екзалтираното състояние до достатъчно добро. При слаби стандарти и политическо влияние дори най-лошият код може да бъде вкаран в производство.
Тестване на ниво две: Известно още като PROD. Вие винаги тествате и го правите старателно. Единственият въпрос е дали щателното тестване се случва преди или след влизане на софтуера в производство.
Извън релсите: Новият CIO спира катастрофата на влака. Неговият предшественик обвинява ръководителя на проекта. Ръководителят на проекта посещава срещите на PMI (Институт по управление на проекти) така, както онези, които имат проблеми с алкохола, отиват на срещи на анонимни алкохолици.

Самозаблуда №4 на CIO: Ние правим ITIL.

Това може да изглежда като семантична дребнавост, но няма такова нещо като "правене" на ITIL. ITIL е рамка, както нейните привърженици търпеливо обясняват на всеки, който има желание да слуша (по принцип малка и апатична аудитория, която не включва нашия самозаблуждаващ се CIO).

ITIL описва нещата, в които ИТ трябва да са добри. Тя не дава рецепта какво да правим, за да сме добри в тях. Това е добре, тъй като няма един начин да се прави каквото и да е от списъка на ITIL, който да работи във всички ситуации. (Не ми ли вярвате? Помислете как бихте изпълнявали ИТ, ако работехте в малка рекламна агенция. Сега помислете за това как бихте го направили в голям доставчик на правителството, специализиран в киберсигурност.)

На всичко отгоре има много главни информационни директори, за които "да се прави ITIL" е равнозначно на добро управление на бюро за обслужване и може би създаване на борд за съвети за промени (CAB), който да седи между разработчиците на приложения (app dev) и ИТ дейностите, така че и двете групи да гледат към CAB вместо едни други.

Самозаблуда №5 на CIO: Ние практикуваме Аgile.

Има ИТ екипи, които са преминали от линейни (waterfall) техники за разработване на приложения към един или повече гъвкави варианти или са в процес да го направят. На всеки, който действително е възприел Agile, вероятно има дузина или повече, които следват вместо това някаква смесена форма agilefall, като спазват стриктно всяка формалност на Scrum и напълно игнорират духа на гъвкавата трансформация.

Както е случаят с толкова много други фирми и ИТ практики, има разлика между поставяне на отметки в списъка и правилно изпълнение на работата, която тези отметки са поставени да следят.

Предполагам, че половината от ИТ екипите, които са избегнали капана на agilefall, са направили завоя към другата посока: те не практикуват Agilе. Вместо това са създали бъркотия, често по заповед на привърженик на линейните техники, който е бил сигурен, преди да започне цялото усилие, че гъвкавите методи са обречени на провал. И е направил всичко възможно да се увери, че неговото пророчество се е самоизпълнило.

Самозаблуда №6 на CIO: Ние практикуваме devops.

Не, не го правите. Вие дори не правите agile. Не можете ли да четете?
Добре, добре. Ако трябва да знаете, въпреки цялата шумотевица около devops техните привърженици не са измислили сътрудничеството. Agile - истинското нещо, а не agilefall - пропагандира сътрудничеството дълго преди появата на devops, въпреки че, да бъдем честни, ИТ дейностите не бяха онези, с които разработчиците по принцип си сътрудничеха.

Ето какво добавят devops към agile:

Първо, екипите за разработване включват ИТ операции по чисто егоистични причини: Те не искат да чакат техните среди да бъдат изградени и не искат да чакат САВ да извърши софтуерни промени. На второ място е повсеместна автоматизация, една наистина добра идея. Да се налага ръчно провеждането на софтуерни промени с тяхното темпо просто е глупаво.

Третото е че, при devops, но не при повечето варианти на agile и определено не при waterfall, софтуерът винаги е в състояние на разгръщане. Не, не, не, не, не. Не в окаяно състояние. В състояние на разгръщане. Измежду многото неудобни реализации за повечето екипи по agile това означава, че devops и Scrum са напълно несъвместими. Kanban работи по-добре.

Съжалявам, че съм приносител на тъжна вест.

Самозаблуда №7 на CIO: Ние имаме култура на обслужване на клиентите.

Чуйте онези хитреци от бюрото за помощ пардон, бюрото за обслужване? Хората от вашето бюро за обслужване са онези, които разпространяват случки с тъпи потребители. Това не са качества на културата на обслужване на клиентите. Едно от тях би започнало с уважение.
Това няма значение, защото, ако имат култура на обслужване на клиентите, техният CIO смята, че останалата част от работата е клиентът.

Много лоша идея. Тя води до неподходящи концепции като връщане - страхотна възможност за губене на време, енергия и доверие, когато се спори за сметката на ИТ. Ако не е напълно ясно защо "култура на обслужване на клиентите" е грешната идея, вижте какво се случва, когато изтриете думата "клиент".

Главните изпълнителни директори трябва да насърчават култура на обслужване в ИТ.
Как могат да знаят дали имат такава култура или нямат? Ако те все още чуват разкази за тъпи потребители, те нямат никаква.

Самозаблуда №8 на CIO: Нашата информационна сигурност е силна.

Помните ли частта за agilefall и контролните списъци? Прекалено често, когато има контролен списък, поставянето на отметки става смисълът на всичко, вместо контролният списък да се използва като начин за проследяване и контрол. Информационната сигурност е изложена на същото предизвикателство, особено когато е включена и сертификация за съвместимост.

PCI, стандартът за сигурност в индустрията на платежните карти, идва наум. Можете да си спомните, че през 2013 г. Target загуби някъде към 40 милиона клиентски записи въпреки съвместимостта с PCI и това съвсем не е единствената загуба на данни от фирми, които са преминали някаква форма на оценка на информационната сигурност.

Ако един CIO смята, че информационната сигурност е силна, той вероятно греши. Само онези главни информационни директори, които са загрижени, че тяхната информационна сигурност може да има някои слабости, могат да бъдат в прилична форма.

Самозаблуда №9 на CIO: Нашите процеси за управление на ИТ гарантират, че ние предприемаме да работим само проекти с висока стойност за бизнеса.

Нека да се върнем отново към съгласуването на целия бизнес. Предполага се, че ИТ управлението трябва да гарантира, че се финансират само проектите с най-висока стойност. Но независимо колко добре е изработен процесът, той все пак се имплементира от същите хора, които на първо място не са "синхронизирани" помежду си. Така че в допълнение към оценяването на стойността на всеки проект за бизнеса в окончателната група от решения са включени пазарлък и чиста злоба.

Добавете към това още една досадна подробност: Проекти, чиято полза е намаляване на разходите, ще имат предимство пред проекти, чиято полза е увеличаване на прихода. Защо? Намаляването на разходите е под контрола на бизнеса. Ако всичко върви по план, разходите ще спадат.

Но увеличаването на приходите призовава за клиенти, които правят това, което искате от тях да правят. Често те не го правят. Не можете да ги накарате да го правят. Трябва да ги убедите. Нелош навик, който вашият изпълнителен директор да придобие между другото, но не е такъв, който достатъчно изпълнителни директори имат.

Искате да направите извод от всичко това? Той е: Ако сте сигурни за всичко, вие почти сигурно грешите. Ако сте CIO и сте сигурни за всяка от тези девет теми или всякакви други, задайте си този прост въпрос: Защо?

Самозаблуда №10 на CIO: Няма нужда да замесваме бизнеса в това.

Да си представим, че ИТ са сформирали група от първокласни мениджъри на взаимоотношения, които да работят по сътрудничеството с бизнеса. След това да си представим, че мениджърите на взаимоотношения вършат работата си, координират нуждите на бизнеса с възможностите на ИТ и така нататък.
Напълно е възможно в тази ситуация проект, който изисква знание за, да кажем, как бизнесът използва информационните технологии, да може да разчита на мениджърите на взаимоотношения да предоставят това знание за проекти, които се нуждаят от него.

Но (винаги има едно "но") когато дойде време за преминаване от планиране към действие и това действие неизбежно ще се отрази върху начина, по който нещата се правят в бизнеса, ще отнеме доста усилие да ги убедите, че наличието на силна връзка с мениджър на взаимоотношения е задоволителен заместител на действително участие на бизнеса.

Това е едно старо, старо правило: Ако смятате да правите нещо, което засяга някого, вие трябва да го включите в него, така че резултатът да е нещо, в което са участвали, а не нещо, което им се е случило.

X