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

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

В некоторых моделях, таких как COBIT 5, управление доступностью и мощностями объединено, так как эти аспекты близки по своей сути и часто взаимосвязаны. Модели, стремящиеся к упрощению и укрупнению процессов, могут объединять сходные функции для снижения сложности управления. Однако такой подход приводит к необходимости постоянного балансирования между противоположными требованиями — обеспечение высокой доступности за счет резервирования может негативно влиять на эффективное использование мощностей, и наоборот. ITIL же придерживается более детализированного подхода, разделяя эти процессы для более целенаправленного управления.

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

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

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

В контексте Service Improvement понятия Continual и Continuous имеют принципиальное различие. Continual Service Improvement (CSI) подразумевает непрерывный, но не обязательно постоянный процесс улучшения, происходящий через регулярные, периодические мероприятия, тогда как Continuous предполагал бы непрерывный безостановочный процесс. В русском языке этот нюанс сложно передать, но точнее будет говорить о «непрекращающемся» совершенствовании, так как улучшения происходят итеративно, в рамках регулярных циклов, а не постоянно без перерывов.

Основной минус среднего арифметического, устраненный в методике с динамическими весами, заключается в том, что при использовании обычного среднего арифметического полный провал одной из областей ответственности (KPI=0%) приводит к незначительному снижению общей оценки (на 10% при 10 показателях). Это создает стимул для сотрудника игнорировать некоторые задачи ("Черт с ними, с 10%, не буду делать эту дурацкую работу, займусь другим"). Методика с динамическими весами решает эту проблему, значительно усиливая влияние низких значений KPI на общий результат, так что провал по одной метрике приводит к существенному снижению общей оценки (например, до 50% вместо 90%), что делает игнорирование любой из областей ответственности экономически невыгодным.

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

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