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

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

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

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

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

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

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

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

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

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