Согласно исследованию, проведенному в 2006 году среди 440 организаций, 33% компаний использовали собственный внутренний подход к организации управления ИТ-процессами (internally developed framework), в то время как только 13% применяли ITIL. Это свидетельствует о том, что значительное количество организаций предпочитает разрабатывать свои собственные методологии управления, адаптированные под их конкретные нужды, вместо использования общепринятых стандартов.

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

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

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

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

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

Существуют несколько ошибочных мнений об учете рабочего времени: первое — что ведение учета занимает 5-10% рабочего времени, хотя фактически это составляет менее 1%; второе — что усложнение системы с большим количеством категорий (более трех) значительно увеличивает время учета, хотя это не подтверждается практикой; третье — что лучше вести учет в конце дня по памяти, что на самом деле приводит к значительным искажениям данных и неточностям в отчетах.

Актуальность информации обеспечивается регулярным пересмотром статей по истечении срока жизни (TTL, Time To Live). За пересмотр отвечают эксперты по областям знаний, которые принимают решение о продолжении публикации статьи или её архивации при приближении срока жизни.

При сравнении приоритетов между техническими и бизнес-задачами важно создать структурированный процесс, учитывающий мнения всех заинтересованных сторон. Владелец продукта, инженеры, менеджеры и другие члены команды должны участвовать в обсуждении ценности каждой задачи. Следует использовать количественные и качественные методы оценки: оценить влияние технических задач на скорость и качество будущей разработки, влияние бизнес-задач на KPI и выручку. Можно применять техники, такие как Weighted Shortest Job First (WSJF), которые учитывают факторы воздействия, сроки и риски. Важно установить критерии оценки приоритетов, согласованные со стратегией компании. Регулярные совместные планировочные встречи и прозрачное обсуждение компромиссов помогут найти баланс. Решение о финальных приоритетах обычно принимает владелец продукта в тесной координации с техническим руководителем, основываясь на комплексной оценке всех факторов.

Обучение важно для ITSM-проектов, так как они направлены на изменение поведения людей: как определяются цели, измеряется прогресс, устанавливаются приоритеты, организуется взаимодействие с клиентами и определяется ценность работы. Обучение помогает формировать знания и навыки сотрудников, что напрямую влияет на их поведение. Оно должно охватывать не только технические аспекты («как делать»), но и объяснять причины изменений («зачем» и «почему именно так»), что особенно важно для ИТ-специалистов как интеллектуальных работников.