Согласно ISO 31000, риск - это влияние неопределенности на цели. Риск-менеджмент, соответственно, представляет собой скоординированные действия по направлению и контролю организации в отношении рисков. В контексте ИТ-управления это означает, что управление проводится не собственно рисками, а организацией с учетом рисков. Управление рисками в ИТ-сфере - это управление организацией с учетом неопределенности. Чем лучше эта неопределенность проработана (корректно идентифицирована, проанализирована и оценена), тем более обоснованные управленческие решения можно принимать и тем более предсказуемые результаты получать. В этом смысле управление рисками становится неотъемлемой частью работы любого менеджера в ИТ-сфере.

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

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

Принципиальный компромисс в ITSM заключается в исключении из области охвата управления уровнями ИТ-услуг вопросов разработки новой функциональности информационных систем. Этот подход предполагает разделение зон ответственности: Application lifecycle management (ALM) используется для разработки, а IT service management (ITSM) — для эксплуатации и сопровождения систем. Такой компромисс позволяет сосредоточиться на поддержании существующих услуг и их доступности, не беря на себя обязательства по гарантии сроков и качества новых разработок.

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

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

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

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

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

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