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

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

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

ITIL 4 не упоминает приоритизацию в процессе решения инцидента (Incident handling and resolution), потому что она переквалифицирована из отдельного шага процесса в фактор успеха всей практики управления инцидентами. Приоритизация остается важной, но теперь рассматривается как более широкая концепция, которая необходима для достижения основной цели практики — минимизации негативного влияния инцидентов. Поскольку приоритизация может происходить многократно и на разных этапах работы с инцидентами, её нецелесообразно ограничивать одним отдельным шагом в процессе. Вместо этого она представляется как элемент, который требуется для эффективного выполнения всей практики в целом.

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

Математический аппарат методики агрегирования KPI с динамическими весами описывается как не сложнее линейных функций. Основная идея проста: это взвешенное среднее, где вес каждого KPI зависит от его значения (чем ниже значение, тем выше вес). Параметром, который управляет системой, является MS (Marginal Score), определяющий, какое значение получит интегральный показатель при полном провале одного из KPI при условии, что остальные выполнены на 100%. Расчет весов и интегрального показателя осуществляется с использованием относительно простых математических зависимостей, что делает методику доступной для практического применения без сложных вычислений.

В контексте прозрачности для процесса Управления инцидентами (INC) упоминается критический фактор успеха: «Улучшать прозрачность и коммуникации в работе процесса». Это означает, что процесс должен быть организован так, чтобы обеспечивать своевременную и понятную информацию всем заинтересованным сторонам о текущем состоянии инцидентов. Данный CSF направлен на минимизацию неопределённости для пользователей и подразумевает создание эффективных механизмов коммуникации, позволяющих быстро и удобно предоставлять информацию о статусе инцидентов.

Стандарт INCITS 494-2012 добавляет к базовому набору RBAC команды, необходимые для работы с расширенным функционалом, в частности, для обработки динамических ограничений. Примеры таких команд включают 'GetRule', 'ParseRule', 'GetValue' и другие, которые предназначены для взаимодействия с внешними политиками и правилами. Эти команды позволяют системе получать правила от внешних источников, обрабатывать (парсить) их и извлекать значения для применения динамических ограничений. Они дополняют базовые команды административного, системного и контрольного типов, обеспечивая расширенный функционал, который позволяет RBAC учитывать внешние факторы при принятии решений о предоставлении доступа.

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

Ассоциация DASA выделяет шесть основных принципов DevOps: 1) Деятельность должна быть ориентирована на заказчика (Customer-Centric Action), включая постоянные инвестиции в продукты и услуги, обеспечивающие максимальную удовлетворённость заказчика, короткие циклы обратной связи и деятельность в духе Lean-стартапов с постоянными инновациями. 2) Ориентация на конечный результат (Create with the End in Mind), что означает отказ от водопадного подхода и процессно-ориентированных моделей в пользу продуктовой ориентации, когда все сотрудники понимают, что создают продукты для реальных заказчиков. 3) Ответственность от начала до конца (End-To-End Responsibility), подразумевающая, что команды отвечают за полный жизненный цикл продукта от концепции до вывода из эксплуатации. 4) Кросс-функциональные автономные команды (Cross-Functional Autonomous Teams), которые должны быть полностью независимыми на протяжении всего жизненного цикла, иметь сбалансированный набор компетенций и T-образные профили специалистов. 5) Постоянное совершенствование (Continuous Improvement), включающее адаптацию к изменяющимся обстоятельствам, сокращение потерь, оптимизацию скорости и затрат, упрощение поставки и постоянное совершенствование продуктов и услуг через экспериментирование и обучение на ошибках. 6) Автоматизируйте всё, что можете (Automate Everything You Can), что охватывает автоматизацию процессов разработки программного обеспечения (непрерывная поставка, непрерывная интеграция, непрерывное развёртывание) и всего инфраструктурного ландшафта (инфраструктура как код).