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

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

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

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

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

Важность удовлетворённости пользователей в контексте управления инцидентами упоминается в нескольких ключевых стандартах и руководствах по управлению ИТ-услугами. В ITIL v3 в разделе целей процесса управления инцидентами прямо указана задача «поддержание удовлетворённости пользователей качеством ИТ-услуг». В ITIL 4, хотя в самой формулировке назначения практики управления инцидентами акцент сделан на скорости восстановления работы, в более подробном описании практики подчёркивается связь с удовлетворённостью пользователей. Аналогичные подходы содержатся в стандарте COBIT и международном стандарте ISO 20000, а также в книге «Управление услугами на основе измерений», где рассматривается значимость измерения и управления уровнем удовлетворённости в контексте предоставления услуг.

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

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

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

ITIL v2 не поддерживает строгого разделения процессов управления инцидентами и обработки сервисных запросов. В нем указывается, что запрос на новую или дополнительную услугу часто рассматривается не как инцидент, а как запрос на изменение (RFC), но далее подчеркивается, что на практике обработка как сбоев инфраструктуры, так и сервисных запросов схожа, поэтому оба типа включаются в определение и область охвата процесса управления инцидентами. Подход ITIL v2 акцентирует внимание на практической стороне и рациональности организации процессов, нежели на теоретическом разделении.