Задачи процесса в ITIL определяются менеджером процесса и закрепляются следующим образом: - Формулировка: описание конкретных функций, которые должен выполнять процесс для соответствия назначению и достижения целей (например, "организация накопления знаний по устранению инцидентов"). - Связь с метриками: указание показателей для контроля выполнения задач. - Документирование: задачи фиксируются в регламенте процесса, так как они меняются реже целей и отражают устоявшуюся технологию. - Ролевая ответственность: менеджер процесса несёт ответственность за актуальность задач, дизайнер процесса консультирует по их соответствию назначению. Пример: для процесса управления проблемами задачей может быть "предоставление обходных решений инцидентов в службу поддержки для сокращения времени простоя".

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

Вместо автоматической функциональной эскалации заявок существуют следующие подходы: 1) Внедрение системы активного мониторинга таймеров SLA с возможностью ручного вмешательства менеджера поддержки при приближении к критическому сроку; 2) Создание гибких маршрутов эскалации с возможностью динамического выбора следующего уровня поддержки на основе диагностики текущего уровня; 3) Внедрение системы раннего предупреждения для специалистов с уведомлениями о приближении к сроку решения инцидента; 4) Организация процесса регулярного аудита заявок, приближающихся к критическим срокам, с возможностью ручной эскалации при необходимости; 5) Внедрение системы внутренних стимулов для специалистов, поощряющей решение проблем на текущем уровне без лишней эскалации. Эти подходы обеспечивают большую гибкость и учитывают специфику каждого инцидента, избегая проблем, связанных с автоматической передачей заявок.

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

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

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

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

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

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

Ценность, которую создает продукт, следует считать разнородной и требующей разделения на разные потоки, если она различается по своей природе для разных групп потребителей или в разных контекстах использования. Критерием является различие в том, как потребитель воспринимает и получает эту ценность. Например, в Twitter выделяются два разных вида ценности: 'легко и удобно коммуницировать, делиться информацией' (для обычных пользователей) и 'получить устойчивую конверсию заинтересованной аудитории в выручку' (для компаний). Эти ценности принципиально отличаются по характеру и измеряются разными показателями (аудитория/активность против финансовых результатов), что указывает на необходимость разделения на разные потоки ценности.