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

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

Распространенные ошибки включают: использование длительности инцидентов как интервалов недоступности (не все инциденты связаны с недоступностью), усреднение доступности для отдельных пользователей (может скрывать влияние простоев на небольшие группы), отказ от измерения доступности на конечной точке потребления (нельзя убедиться в реальном доступе пользователя), и использование примитивных средств мониторинга (например, проверка доступности через ping, которая не отражает возможности выполнения критических операций).

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

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

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

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

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

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

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