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

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

Время реакции группы на назначение инцидента (время с момента назначения до переназначения в другую группу или окончания работы) включено в параметр ti, который представляет собой общее время обработки i-го инцидента силами данной группы. Чем дольше группа реагирует на назначенный инцидент, тем больше значение ti, а следовательно, тем больше доля группы во времени обработки и тем ниже её KPI в случае просрочки. Поэтому метрика стимулирует группы оперативно приступать к работе над назначенными инцидентами, даже если инцидент был передан уже близко к окончанию срока.

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

Учет времени необходим для объективной оценки рабочей нагрузки, потому что субъективные оценки и попытки вспомнить затраченное время часто приводят к серьезным искажениям. Как показано в примере, сотрудник сначала заявил о 215% загрузки, которая после проверки снизилась до 85%. Только точный учет позволяет получить реальную картину распределения времени и нагрузки, что критически важно для планирования, распределения задач и оценки продуктивности.

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

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

Цикл Деминга-Шухарта представляет собой метод непрерывного совершенствования процессов, состоящий из четырех этапов: Plan (Планирование), Do (Выполнение), Check (Проверка), Act (Действие). В управлении ИТ этот цикл применяется для постоянного улучшения процессов, позволяя организациям анализировать текущее состояние, внедрять изменения, проверять их эффективность и корректировать дальнейшие действия. На практике цикл используется для оптимизации различных ИТ-процессов, таких как управление инцидентами, управление изменениями и управление проблемами.

Шаг Plan (Планируй) в цикле Деминга предполагает разработку плана улучшений, формулировку гипотез и определение метрик для измерения результатов. В то время как шаг Act (Корректируй) сосредоточен на принятии решений относительно дальнейших действий после анализа результатов проверки (Check). Act включает либо внедрение успешных улучшений в постоянную практику, либо игнорирование неудачных результатов, либо запуск цикла заново с учетом накопленного опыта. Таким образом, Plan направлен на планирование изменений, а Act — на определение дальнейшего развития процесса после реализации и оценки этих изменений.

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