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

Это означает, что успешное завершение проекта — это только первый шаг на пути к достижению истинного результата. Запуск нового процесса или внедрение изменений требует дальнейшего развития и поддержки, чтобы они укоренились в организации. Без этого даже самый успешный проект останется временным достижением, не вписавшись в повседневную деятельность компании и не принеся долгосрочной пользы.

Для выражения эмпатии клиенту у сотрудника должны быть развиты следующие навыки: активное слушание (умение слушать без перебивания, давая клиенту возможность высказаться), признание чувств клиента (выражение понимания того, что он чувствует, например, «Я понимаю, как это может быть неприятно»), контроль собственных эмоций (способность сохранять спокойствие даже в стрессовых ситуациях), корректность в обращении (использование имени клиента, уважительный тон), умение признавать ошибки и извиняться от имени компании, задавание уточняющих вопросов вместо поспешных решений. Также важно умение проявлять искренний интерес к проблеме клиента и демонстрировать готовность помочь. Навыки выражения эмпатии включают в себя также способность искать общие интересы и вовлекать клиента в процесс решения проблемы, чтобы он чувствовал себя частью решения, а не оппонентом.

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

CMDB (Configuration Management Database) используется для хранения информации о компонентах инфраструктуры и их связях. Для прогнозирования влияния инфраструктурных инцидентов на ИТ-услуги требуется максимально детальное описание этих связей. Однако на практике это сложно реализовать, так как связи могут быть сложными, динамичными и требуют постоянного обновления. Неполная или неточная информация в CMDB снижает эффективность прогнозов и увеличивает риск ошибок в диагностике.

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

Практические упражнения, помогающие понять разницу между товаром и услугой, включают в себя анализ примеров из реальной жизни с акцентом на выявление рисков и затрат, которые клиент перекладывает на поставщика. Например, участникам предлагают взять простой товар (шоколадку, автомобиль) и преобразовать его в услугу, определяя: 1) Какие риски и затраты клиент может переложить на поставщика; 2) Какие ресурсы необходимы для предоставления услуги; 3) Какие операции должен выполнять поставщик. Другой вариант упражнения - анализ существующих бизнес-моделей (каршеринг vs покупка автомобиля, аренда жилья vs покупка квартиры) и выделение компонентов услуги: товара, ресурса и операций. Эти упражнения помогают участникам глубже понять концепцию услуги в рамках ITIL4.

Роль координатора изменений, хотя и не упомянута в официальной документации ITIL, широко используется в большинстве распространенных вендорских процессных моделях. Например, она присутствует в моделях компаний BMC, HP и IBM. В IBM Tivoli Unified Process эта роль называется 'Владелец изменений', что может вызывать терминологическую путаницу из-за многозначного использования слова 'Owner' в ИТ-управлении. Несмотря на отсутствие официального признания этой роли в ITIL, на практике внедрение управления изменениями в крупных компаниях практически всегда включает назначение координаторов изменений

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

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