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

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

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

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

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

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

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

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

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

Практика ведения каталога технических услуг и OLA не применима ко всем компаниям, потому что сервисный подход вообще реализован лишь в небольшом количестве организаций, и только к очень небольшой доле этих организаций применима именно практика ведения каталога технических услуг и OLA. Это связано с тем, что такие документы и практики значительно влияют на другие процессы, отношения между подразделениями и оргструктуру, и их введение может быть избыточным или неоправданным в компаниях с простой структурой или без четкого сервисного подхода. О необходимости быть осторожнее с внедрением таких практик уже писали Pink Elephant (около 2006 года) и IT Skeptic (около 2011 года).