Традиционно временем решения инцидента в SLA считается период от регистрации обращения до завершения работ специалистом. Это включает в себя все этапы обработки инцидента, начиная с момента его фиксации в системе и до полного устранения проблемы и закрытия обращения.

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

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

Концепция Definition of Done решает проблему неоднозначного понимания того, что считается завершенной работой. Отсутствие четких критериев завершения приводит к недопониманию между различными участниками процесса (разработчиками, тестировщиками, менеджерами), преждевременному объявлению задач завершенными и последующим проблемам в эксплуатации. Использование Definition of Done обеспечивает единое понимание завершения работы, повышает качество продукта, минимизирует риски и обеспечивает прозрачность процесса для всех заинтересованных сторон.

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

Метод анализа 5-Why's предполагает многократное задавание вопроса «почему» (пять раз) для выявления корневой причины проблемы. В процессе управления проблемами ITIL метод позволяет последовательно углубляться в анализ каждой последующей причины предыдущего явления. Например, при анализе неработающего принтера такой подход выявляет цепочку: неисправный нагревательный элемент → перепады напряжения → нестабильная работа подстанции → её устаревание → отсутствие модернизации. Цель метода — определить первопричину, хотя на практике часто останавливаются на том этапе, где обнаруживается граница зоны влияния поставщика услуг.

Для вычисления необходимого количества сделок нужно разделить общий план продаж на средний чек. Например, если план продаж на год составляет 1440 млн рублей, а средний чек равен 10 000 рублей, то ежемесячное количество сделок будет равно 1440 млн / 12 месяцев / 10 000 рублей = 12 000 сделок в месяц. Это значение используется для дальнейших расчетов нагрузки на ИТ-системы, определения необходимого количества продавцов и прогнозирования обращений в службу поддержки.

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

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

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