TTV (Time-To-Value) - это метрика, измеряющая скорость и простоту всех шагов, необходимых для того, чтобы пользователь или заказчик получил ценность от продукта после проявления первоначального интереса. Эта метрика включает время на пробную версию, внедрение продукта и достижение первых результатов от его использования. TTV важен, потому что чем быстрее заказчик увидит пользу от продукта, тем выше вероятность его успешного внедрения и удержания. Для многих продуктов, особенно B2B и корпоративных, внедрение составляет значительную часть общей стоимости владения (TCO), поэтому оптимизация этого процесса становится критически важной характеристикой продукта. Сокращение TTV позволяет улучшить пользовательский опыт, увеличить удовлетворенность и повысить показатели Retention. Эта метрика особенно важна для enterprise-продуктов, где время внедрения может измеряться месяцами и значительно влиять на восприятие продукта заказчиком.

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

Управление доступностью в ITIL представляет собой процесс, задачи которого включают создание и ведение плана доступности, участие в диагностике и решении инцидентов и проблем, связанных с доступностью, оценку влияния изменений на доступность услуг и ресурсов. Однако, согласно анализу, эти задачи фактически пересекаются с другими процессами, такими как управление инцидентами, проблемами, изменениями, управление уровнями сервиса (SLM), управление непрерывностью и мощностями. Процесс управления доступностью считается уникальным изобретением ITIL, так как в других стандартах он либо не выделен отдельно, либо объединен с другими процессами.

Для работы с массовыми обращениями, вызванными крупными инцидентами, следует применять следующий подход: 1. Оценить текущую способность процесса справляться с такими ситуациями, проверив наличие и эффективность специализированных процедур для массовых обращений 2. Если такие процедуры отсутствуют или неэффективны, разработать стратегию работы с массовыми обращениями, включая приоритизацию и распределение ресурсов 3. Создать специализированные шаблоны и стандартные ответы для типовых ситуаций 4. Усилить критические участки процесса дополнительным персоналом и ресурсами 5. Рассмотреть возможность временного отказа от необязательных этапов обработки для ускорения основного процесса 6. Внедрить специальные инструменты для быстрой классификации и маршрутизации массовых обращений 7. Организовать оперативный информационный центр для координации действий всех задействованных групп 8. Провести пост-инцидентный анализ для выявления уроков и внесения изменений в процессы, чтобы избежать подобных ситуаций в будущем Ключевым является оперативная реакция и четкая структура действий, которая позволяет минимизировать время простоя и негативное воздействие на пользователей.

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

Для значительных инцидентов необходима отдельная процедура обработки, поскольку обычные процедуры управления инцидентами оказываются неэффективными в ситуациях с большим масштабом воздействия и сложной координацией между множеством подразделений. Стандарт ISO/IEC 20000:2011 требует, чтобы поставщик услуг разработал документированную процедуру для обработки значительных инцидентов, включая назначение ответственного лица, уведомление топ-менеджмента и проведение анализа после восстановления услуг. Это связано с необходимостью специальных мероприятий для восстановления работы большого числа пользователей, координации действий различных отделов (ИТ, административного, информационной безопасности, связи) и обработки массовых обращений.

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

Согласно ITIL, назначение процесса управления конфигурациями заключается в обеспечении корректного контроля над активами, необходимыми для предоставления ИТ-услуг, и в предоставлении точной и надёжной информации об этих активах в любое требуемое время и в требуемом месте. Это включает в себя создание, обновление и поддержание базы данных конфигураций (CMDB), которая служит единым источником истины для всех сведений, связанных с конфигурационными элементами и их взаимосвязями.

Для определения истинной корневой причины с использованием метода 5-Why's необходимо последовательно задавать вопрос «почему» к каждому выявленному симптому, формируя цепочку причинно-следственных связей. Метод предполагает, что после пятого уровня анализа будет обнаружена глубинная причина. Однако на практике решающее значение имеет не количество шагов, а достижение точки, где поставщик услуг может повлиять на решение. Например, при анализе принтера анализ останавливается на уровне устаревшей подстанции, так как дальнейшие действия выходят за рамки ответственности поставщика.

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