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

В ITIL отсутствует градация уровня экстренности, потому что emergency-изменения по определению требуют немедленного выполнения без промедления. Если ситуация допускает вариации вроде «немного срочно» или «очень срочно», это уже не emergency — такие случаи обрабатываются в рамках стандартных или срочных изменений. Градация запутала бы процесс, ведь экстренное изменение подразумевает, что все ресурсы должны быть переключены на его реализацию в ущерб другим задачам. Например, если сайт компании падает, команда не анализирует «степень срочности» — она сразу приступает к восстановлению.

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

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

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

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

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

Project Oxygen – это исследовательский проект Google, направленный на изучение роли менеджеров в эффективности работы компании. Проект был запущен в 2008 году и изначально ставил целью доказать, что менеджеры не имеют существенного влияния на результаты работы сотрудников. Однако исследования показали обратное: роль руководителей критически важна для успеха организации. В результате Project Oxygen был разработан перечень из восьми ключевых качеств, которыми должен обладать хороший менеджер, такие как умение быть коучем, эффективное делегирование, интерес к успехам сотрудников и другие. Этот перечень используется в Google для подготовки менеджеров и формирования организационной структуры.

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

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