Три приоритета ИТ-директора


Оригинал: The 3 IT processes CIOs need most
Автор: Боб Льюис (Bob Lewis)

Седьмой принцип «Keep the Joint Running Manifesto» гласит: чтобы действовать стратегически, надо сначала стать компетентным. Вся деятельность в сфере ИТ базируется на методиках и практиках. В них-то и проявляется компетентность или ее отсутствие.

Ранее мы вели речь о суровых реалиях «совершенствования» ИТ-процессов и практик. Сегодня поговорим об аспектах, которым ИТ-директору стоит уделить особое внимание.

Начнем с базового принципа: руководитель не должен одновременно заниматься более чем тремя проектами. Стоит превысить это магическое число, и вы потеряете концентрацию, а с ней и видение цели. Какие же три точки приложения усилий стоит выбрать ИТ-директору?

На чем НЕ следует концентрироваться: рутинные процессы ИТ

Первое что приходит на ум, когда речь заходит о разработке программы совершенствования процессов,- широко известная методика ITIL. Это распространенная ошибка.

Внедрение практик и методов ITIL само по себе не является ошибкой. Философия и практики ITIL выдержали проверку временем и заслуживают доверия. Проблема в том, что в центре внимания ITIL находятся рутинные ИТ-процессы, которые замечают лишь когда возникают проблемы. А вы, как ИТ-директор, хотели бы привлекать внимание не к проблемам, а к достижениям.

Таким образом, если вы стремитесь улучшить управление доступностью, мощностями, эффективностью, жизненным циклом инфраструктуры, системное администрирование и в особенности управление изменениями, то вам стоит убедиться, что ваши повседневные ИТ-процессы находятся в надежных руках, и осознать, что критерием успеха в этой сфере является «индекс незаметности», подразумевающий, что только вы один замечаете незаметность ИТ-процессов для остальных.

В качестве ИТ-директора вы должны понимать, что повседневные ИТ-процессы в целом крайне важны, но значимы в стратегическом плане лишь в той степени, в какой без их успешного выполнения невозможна реализация стратегии в целом. Делегируйте рутинные ИТ-обязанности, убедившись, что тот, кому вы их передали, располагает всеми необходимыми инструментами и ресурсами.

Приоритет номер один: служба технической поддержки

Если работа вашего хелпдеска далека от идеала, то наведение порядка в этой области должно стать вашей главной задачей, так как он определяет репутацию ИТ в целом.

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

Службой техподдержки начинается и заканчивается взаимодействие бизнеса и ИТ. Поэтому если вы слышите, как ее критикуют за глаза; или ваши коллеги начинают интересоваться у вас, почему ИТ-служба не в курсе, что система «лежит», пока пользователи сами не сообщат об этом в техподдержку; или вы замечаете, что сотрудники техподдержки рассказывают друг другу истории о пользователях-идиотах; или кто-либо обращается в техподдержку за оперативным решением проблемы, а получает лишь номер тикета — сделайте наведение порядка в техподдержке вашим личным делом. Хорошо налаженная техническая поддержка является важной составляющей успеха управления ИТ-инфраструктурой в организации.

Приоритет номер два: поддержка приложений

Правило 1. Если ваша команда все еще следует «водопадной» модели разработки приложений, то чего вы ждете? Начинайте переводить их на аджайл, лично контролируя план этого перехода и его реализацию.

Правило 2. Скрам — это еще не весь аджайл. Не хватайтесь за скрам только потому, что «все его используют», а выберите вариант аджайла, соответствующий вашим реалиям.

Правило 3. Большинство модификаций аджайла нацелены на управление процессом разработки приложений. В то же время большинство ИТ-подразделений следуют правилу «если можно — покупай, если не получается — разрабатывай». Если это ваш случай, то полностью откажитесь от скрама, вместо этого обратите внимание на методики CRP (conference room pilot) и ATDD (acceptance test-driven development).

Правило 4. Большинство модификаций аджайла нацелены на разработку программных продуктов, в то время как большинству бизнесов ИТ нужен, чтобы вместе осуществлять изменения. Адаптируйте выбранный вариант аджайла к этой цели.

Приоритет номер три: управление ИТ-архитектурой

Более подробно о методике оценки качества и преимуществах самой ИТ-архитектуры мы поговорим в следующих статьях.

Очевидно, что слабо проработанная архитектура — следствие слабой организации соответствующих практик. Какие еще признаки могут подсказать, что управление ИТ-архитектурой нуждается в улучшении?

На удивление и к большому разочарованию, очень часто можно услышать слова «мы не знаем, насколько хороша наша ИТ-архитектура». Что еще может пойти не так?

  1. У вас не опубликован и не доведен до сведения персонала короткий (не более десятка пунктов) перечень основополагающих архитектурных принципов. Их формулировки должны быть лаконичными, простыми для понимания и без профессионального жаргона.
  2. Не разработан и не введен в действие набор стандартов, которые:
    • основаны на вышеуказанных принципах
    • хорошо задокументированы
    • регулярно обновляются (имеет смысл делать это ежеквартально)
  3. Отсутствует стандартная практика управления жизненным циклом ИТ-архитектуры, увязанная с планированием и бюджетированием.
  4. Нет облачной стратегии, построенной вокруг ИТ-архитектуры на упомянутых ранее принципах и стандартах, и понимания, что понятие «облачный» относится к архитектуре, а не к хранению и подходам к обработке данных.

Но даже отсутствие перечисленных изъянов не гарантирует успех. ИТ-архитектура, как и архитектура предприятия, постоянно рискует из средства создания дополнительной ценности для потребителя превратиться в бюрократическое болото.

К слову, этот риск характерен не только для архитектуры — ему подвержен любой орган или подразделение, наделенные правом инспектировать и критиковать созидательную работу других. Первоклассная архитектура требует мышления, не скованного бюрократизмом. Ей также необходимо финансирование, поскольку разработка приложения с приемлемым функционалом обходится дешевле, чем такая же разработка, выполненная с соблюдением архитектурных стандартов.

Маловероятно, что среднестатистический спонсор пожелает оплачивать эту разницу, поэтому она должна компенсироваться из фонда, выделенного на поддержку архитектуры.

Цель управления ИТ-архитектурой состоит в том, чтобы построить качественную архитектуру, прибегая к директивным мерам лишь в исключительных случаях. Вторая цель — продемонстрировать высшему руководству, что грамотно выстроенная ИТ-архитектура является разумной инвестицией. Поэтому сложно не прийти к выводу, что даже при самых благоприятных обстоятельствах ИТ-директору необходимо лично контролировать работу архитектурной команды.

Что с информационной безопасностью?

В современном мире, где поток информационных угроз для бизнеса щедро питается организованной киберпреступностью и злоумышленниками-одиночками, а потенциальный ущерб от кибератак характеризуется уже не как серьезный, а как огромный, информационная безопасность стала одним из приоритетов в ИТ. Однако, подобно рутинным процессам ИТ, эффективность информационной безопасности измеряется собственной разновидностью «индекса незаметности».

Но здесь с этим сложнее, потому что эффективная информационная безопасность должна быть всепроникающей, что означает частичную утрату незаметности.

Кроме того, в отсутствии качественной ИТ-архитектуры неизбежны дыры в информационной безопасности. Поэтому сделайте информационную безопасность аспектом архитектурной деятельности, и вы сможете присматривать за ней, не распыляя свое внимание.

Как быть с инновациями в ИТ и с цифровой трансформацией

Если вы зададитесь вопросом, что является источником новых возможностей для бизнеса, то обнаружите, что информационные технологии входят в тройку лидеров. В качестве ИТ-директора вы можете или взять на себя ответственность за ИТ-инновации, или выступить с идеей ввести пост директора по цифровой трансформации.

Второй вариант может рассматриваться как признание вами собственной слабости. Кроме того, он чреват двоевластием в ИТ, когда директор по цифровой трансформации генерирует инициативы, а вы чаще всего их хороните. Поскольку в глазах окружающих все упирается в вас, на этом ваша карьера может закончиться.

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

Что делать с теневым ИТ

«Теневое ИТ», «подпольное ИТ», «самодельное ИТ» — многие ИТ-директора изо всех сил стремятся искоренить самодеятельность в области ИТ, но такая борьба выглядит делом безнадежным.

Вместе с тем такое «дилетантство» в ИТ в большей степени представляет собой возможность, а не проблему. Оно позволяет существенно увеличить пропускную способность ИТ-подразделения без дополнительных затрат (по крайней мере, без видимого увеличения затрат).

А отрицательных моментов большей частью можно избежать. Чаще всего от ИТ требуются лишь небольшие консультации, обеспечивающие следование стандартам ИТ-архитектуры. Взамен архитектурная группа получит документацию, выводящую эту деятельность из тени. Таким образом, поддержка теневого ИТ становится еще одним аспектом ИТ-архитектуры.

Заключение

Компетентность в ИТ подразумевает выполнение работы с использованием грамотно разработанных, четко определенных и хорошо документированных методов и практик. За все перечисленное отвечает ИТ-директор, однако на практике он не в состоянии лично курировать изменения более чем в трех направлениях деятельности.

Для большинства организаций в первую очередь внимания ИТ-директора требуют три области: поддержка пользователей, поддержка приложений и управление ИТ-архитектурой. Доведите их до блеска, и успех будет очевиден всем.

Но успех возможен только если налажены базовые ИТ-процессы, которые, как это не парадоксально, ИТ-директор должен делегировать в надежные руки. Если вам это не удастся, то у вас попросту не останется времени и сил на  главную тройку.

Обсудить