Методология формирования ИТ-бюджета по ITIL состоит из пяти основных этапов: получение бизнес-планов через Business Relationship Management (BRM) и Service Level Management (SLM), согласование планов потребления услуг с клиентами (SLM и управление емкостью сервисов), подготовка планов по ресурсному обеспечению включая персонал (Resource Capacity Management), вычисление стоимости ресурсов и услуг с аллокацией косвенных затрат (Financial Management for IT), и окончательный расчет стоимости услуг на основе потребления, приводящий к обоснованному операционному бюджету ИТ.

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

FTA можно интегрировать в процессы ITIL следующим образом: в рамках Service Design метод помогает выявить потенциальные отказы при проектировании системы, определять требования к компонентам на основе показателей гарантии и отсеивать заведомо ненадежные архитектурные решения; для управления непрерывностью ИТ-услуг (ITSCM) FTA позволяет понять, какие комбинации событий приведут к нарушению доступности критичной функциональности, и подготовиться к ним, определив меры предотвращения или пути быстрого восстановления. При этом анализ помогает установить точные зависимости между сбоями конфигурационных единиц (КЕ) и отказом функциональности, что упрощает расчет целевых показателей восстановления (RTO, RPO) для конкретных КЕ.

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

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

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

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

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

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

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