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

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

Главное отличие COBIT 5 PAM от COBIT 4.1 состоит в методологии оценки зрелости процессов. COBIT 4.1 использовал шкалу зрелости с описанием содержания процессов на каждом уровне, что было более наглядно, но менее объективно. COBIT 5 PAM, следуя стандарту ISO/IEC 15504, фокусируется на оценке управленческой надстройки процессов через шесть уровней способности, не зависящих от содержания процесса. Это позволяет проводить более объективные и воспроизводимые оценки, применимые к любым процессам и отраслям. При этом COBIT 5 PAM становится более абстрактной и сложной для понимания, но повышает качество оценки за счет устранения субъективных интерпретаций и опоры на реальные свидетельства выполнения управленческих практик.

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

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

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

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

Несоответствие связано с тем, что исследования основаны на выборках, которые могут не охватывать специфические сценарии использования ИТ-услуг. Например, в «Дикси» в 2022 году было 4,6 обращения на пользователя, что выше средних значений из отчетов. Это объясняется особенностями розничной сети: высокой нагрузкой на оборудование, спецификой бизнес-процессов, возможным отсутствием базы знаний или недостаточной ИТ-грамотностью сотрудников. Такие локальные факторы делают прямое сравнение данных сложным.

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

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