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

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

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

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

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

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

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

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

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

Для учёта степени превышения срока обработки метрика может быть модифицирована за счёт добавления весового коэффициента wi, который учитывает, насколько сильно просрочен инцидент. Если инцидент решен в срок, wi=1. Если срок превышен, wi определяется как отношение фактического времени решения инцидента Ti к установленному сроку. Формула переписывается в виде: Кгруппы = (1/N) * Σ(wi * (1 - (ti/Ti) * vi)). Также можно ввести рейтинг ответственности ri = (ti/Ti) * vi. Тогда метрика принимает вид взвешенного арифметического среднего: Кгруппы = (1/N) * Σ(wi * (1 - ri)).