Основы ITIL 4: Современное управление IT-услугами

Введение в ITIL 4: Ключевые концепции управления услугами и совместное создание ценности

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

От ITIL v3 к ITIL 4: Смена парадигмы

Долгое время в IT-индустрии господствовал подход, при котором IT-отдел создавал продукт или услугу в изоляции, а затем «перебрасывал» его бизнесу, ожидая благодарности. Это часто приводило к разрыву ожиданий: IT считали, что все работает отлично (серверы доступны, код написан), а бизнес был недоволен, так как не получал реальной пользы.

ITIL 4 (Information Technology Infrastructure Library) меняет правила игры. Главное отличие новой версии — переход от доставки услуг (Service Delivery) к совместному созданию ценности (Value Co-creation).

> ITIL 4 — это фреймворк (набор лучших практик) для управления IT-услугами, который помогает организациям адаптироваться к цифровой трансформации и создавать ценность для своих потребителей.

!Эволюция подхода: от односторонней доставки к совместному созданию ценности.

Что такое управление услугами?

Прежде чем углубляться в детали, давайте определим базовые понятия.

Управление услугами (Service Management) — это набор специализированных организационных возможностей для предоставления ценности заказчикам в форме услуг.

Но что же такое сама услуга?

Услуга (Service) — это способ обеспечения совместного создания ценности путем содействия заказчикам в получении конечных результатов, которых они хотят достичь, без необходимости нести специфические затраты и риски.

Разберем это определение на примере облачного хранилища данных (например, Google Drive или Dropbox):

Результат: Вы хотите надежно хранить файлы и иметь к ним доступ отовсюду.

Специфические затраты: Вам не нужно покупать собственные жесткие диски, серверы и нанимать администраторов.

Специфические риски: Вы не беспокоитесь о том, что диск сгорит или электричество отключится — это берет на себя провайдер.

Концепция ценности: Полезность и Гарантия

Ценность (Value) — это воспринимаемая выгода, польза и важность чего-либо. В ITIL 4 ценность не является абсолютной величиной; она субъективна. То, что ценно для одного заказчика, может быть бесполезно для другого.

Чтобы услуга создавала ценность, она должна обладать двумя характеристиками:

Полезность (Utility) — пригодность для цели. Отвечает на вопрос: «Что делает услуга?». Она должна либо повышать производительность потребителя, либо снимать с него ограничения.

Гарантия (Warranty) — пригодность для использования. Отвечает на вопрос: «Как услуга выполняется?». Это уверенность в том, что услуга будет соответствовать согласованным требованиям.

Гарантия обычно включает четыре аспекта: * Доступность: Услуга доступна, когда она нужна. * Мощность: Услуга справляется с нагрузкой. * Непрерывность: Услуга восстанавливается после сбоев. * Безопасность: Данные защищены.

Важно запомнить простое правило:

> Ценность = Полезность + Гарантия

Если у услуги отличная функциональность (Полезность), но она постоянно «падает» (нет Гарантии), ценности нет. И наоборот: если услуга работает идеально стабильно (Гарантия), но не делает того, что нужно пользователю (нет Полезности), она также бесполезна.

Ключевые заинтересованные стороны

В процессе управления услугами участвуют не просто «IT» и «Бизнес». ITIL 4 выделяет конкретные роли в сервисных отношениях.

Поставщик услуг (Service Provider)

Это роль, которую выполняет организация, предоставляющая услуги. Это может быть: * Внутренний IT-отдел. * Внешняя компания-аутсорсер.

Потребитель услуг (Service Consumer)

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

| Роль | Описание | Пример (Корпоративная почта) | | :--- | :--- | :--- | | Заказчик (Customer) | Тот, кто определяет требования к услуге и берет на себя ответственность за результаты потребления. Часто именно он платит за услугу (из бюджета департамента). | Директор по маркетингу, который заказывает почтовый сервис для своих сотрудников. | | Пользователь (User) | Тот, кто непосредственно использует услугу в повседневной работе. | Сотрудник отдела маркетинга, отправляющий письма. | | Спонсор (Sponsor) | Тот, кто утверждает бюджет на потребление услуги. | Финансовый директор, подписывающий счет на оплату лицензий. |

!Три роли потребителя услуг: Заказчик, Пользователь и Спонсор.

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

Предложение услуг (Service Offering)

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

Предложение услуг может включать три компонента:

Товары (Goods): Передача прав собственности. Потребитель получает вещь навсегда.

Пример:* Выдача корпоративного ноутбука или мобильного телефона.

Доступ к ресурсам (Access to Resources): Предоставление прав использования на определенный срок. Собственность остается у провайдера.

Пример:* Доступ к облачному серверу, лицензия на Office 365 по подписке.

Сервисные действия (Service Actions): Действия, выполняемые провайдером для нужд потребителя.

Пример:* Работа техподдержки, настройка оборудования, консультация.

Сервисные отношения (Service Relationships)

Как мы уже говорили, создание ценности — это двусторонний процесс. Он реализуется через Сервисные отношения.

Эта модель состоит из трех этапов:

Предоставление услуг (Service Provision): Действия провайдера. Сюда входит управление ресурсами, предоставление доступа, выполнение сервисных действий и поддержка пользователей.

Потребление услуг (Service Consumption): Действия потребителя. Это управление своими ресурсами, необходимыми для использования услуги (например, наличие интернета для доступа к облаку), и непосредственно использование услуги.

Управление сервисными отношениями: Совместная деятельность провайдера и потребителя для обеспечения постоянного сотворчества ценности.

Пример сервисных отношений

Представьте, что вы — интернет-провайдер (Поставщик), а ваш клиент — фрилансер (Потребитель).

* Ваша часть (Provision): Вы прокладываете кабель, настраиваете оборудование, обеспечиваете сигнал. * Часть клиента (Consumption): Он покупает роутер, подключает к нему ноутбук и использует интернет для работы. * Совместное создание ценности: Если интернет работает быстро (Гарантия) и позволяет фрилансеру сдать проект вовремя (Полезность), ценность создана. Если клиент не оплатил счет или его роутер сломался, ценности не будет, даже если ваш сигнал идеален. Именно поэтому сотрудничество необходимо.

Заключение

В этой статье мы заложили фундамент для понимания ITIL 4. Мы выяснили, что современное управление услугами — это не односторонняя доставка, а совместное путешествие провайдера и потребителя. Мы разобрали структуру потребителя (Заказчик, Пользователь, Спонсор) и формулу ценности (Полезность + Гарантия).

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

Четыре измерения управления услугами: Люди, технологии, партнеры и процессы

В предыдущей статье мы определили, что главная цель управления услугами — это совместное создание ценности. Мы узнали, что ценность складывается из полезности (что услуга делает) и гарантии (как она работает). Но как именно организации создают такие услуги? Достаточно ли просто купить дорогой сервер или нанять гениального программиста?

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

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

Эти четыре измерения:

Организации и люди

Информация и технологии

Партнеры и поставщики

Потоки ценности и процессы

Если проигнорировать хотя бы одно из них, услуга может стать нестабильной, дорогой или вовсе ненужной заказчику.

1. Организации и люди (Organizations and People)

Первое измерение касается не только количества сотрудников, но и того, как они организованы, какова их культура и компетенции.

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

Ключевые элементы этого измерения:

* Роли и обязанности: Четкое понимание того, кто за что отвечает. * Формальная организационная структура: Иерархия, отделы, команды. * Культура: Общие ценности и убеждения. Например, культура доверия и прозрачности важнее строгих инструкций. * Навыки и компетенции: Не только технические знания (hard skills), но и навыки общения, управления и лидерства (soft skills).

> Организация — это не просто набор людей, это структура, объединенная общими целями.

Одной из главных проблем в этом измерении являются «информационные колодцы» (silos). Это ситуация, когда отделы (например, Разработка и Поддержка) не общаются друг с другом, скрывают информацию и преследуют разные цели. ITIL 4 призывает разрушать эти барьеры через кросс-функциональные команды.

2. Информация и технологии (Information and Technology)

В современном мире практически любая услуга опирается на технологии. Это измерение охватывает технологии, необходимые для управления услугами (например, система Service Desk), и технологии, составляющие саму услугу (например, серверы, базы данных, приложения).

При рассмотрении этого измерения важно задать три вопроса:

Какая информация необходима для управления услугами?

Какие технологии нужны для поддержки этой информации?

Как защитить эту информацию и технологии?

Информация как актив

Информация — это кровь бизнеса. Управление знаниями, защита данных клиентов (GDPR, 152-ФЗ) и доступность информации для принятия решений — критически важные аспекты.

Выбор технологий

Не существует универсальной технологии. При выборе инструментов (будь то искусственный интеллект, облачные вычисления или блокчейн) нужно учитывать: * Совместима ли технология с текущей архитектурой? * Готовы ли люди (первое измерение) использовать её? * Окупаются ли затраты на внедрение?

!Выбор технологии должен основываться на потребностях бизнеса, а не на моде.

3. Партнеры и поставщики (Partners and Suppliers)

Ни одна современная компания не делает всё самостоятельно. Мы используем электричество от городской сети, интернет от провайдера, облачные сервисы от гигантов вроде Amazon или Yandex, и, возможно, нанимаем внешних разработчиков.

Это измерение охватывает отношения организации с другими компаниями, которые участвуют в создании ценности.

Спектр отношений может варьироваться:

| Тип отношений | Описание | Пример | | :--- | :--- | :--- | | Поставка товара | Формальные отношения, низкий уровень интеграции. Купил и забыл. | Покупка лицензий на антивирус или партии ноутбуков. | | Сервисное партнерство | Тесное сотрудничество, общие цели и риски. | Аутсорсинг разработки ПО, где команда подрядчика работает как часть вашей компании. |

Стратегия: Сделать самим или купить? (Build vs Buy)

Главный вопрос этого измерения — что делать своими силами, а что отдать партнерам. На это влияют: * Стратегические компетенции: Если вы банк, разработка банковского приложения — ваша ключевая компетенция, её лучше оставить внутри. А уборку офиса или обслуживание принтеров лучше отдать на аутсорс. * Дефицит ресурсов: Если у вас нет специалистов по кибербезопасности, надежнее нанять профильную компанию. * Скорость: Купить готовое решение часто быстрее, чем разрабатывать своё.

4. Потоки ценности и процессы (Value Streams and Processes)

Это измерение отвечает на вопрос «КАК?». Как различные части организации работают вместе, чтобы превратить запрос пользователя в ценный результат?

Здесь ITIL 4 вводит два важнейших понятия.

Процессы

Процесс — это набор взаимосвязанных действий, которые преобразуют входы в выходы. Процессы описывают, что делается. Они обычно хорошо документированы и структурированы. Пример:* Процесс управления инцидентами (регистрация сбоя -> классификация -> решение -> закрытие).

Потоки ценности (Value Streams)

Поток ценности — это серия шагов, которые организация предпринимает для создания и доставки продуктов и услуг потребителю. Поток ценности объединяет разные процессы и людей для достижения конкретной цели.

В чем разница? Процесс — это инструкция для конкретной задачи. Поток ценности — это путь через всю организацию.

Рассмотрим пример потока ценности «Обработка запроса на новый ноутбук»:

Пользователь оставляет заявку (Процесс управления запросами).

Менеджер одобряет бюджет (Финансовый процесс).

Закупщики заказывают ноутбук у поставщика (Управление поставщиками).

IT-отдел настраивает ноутбук (Управление активами и конфигурациями).

Курьер доставляет ноутбук пользователю (Логистика).

!Поток ценности объединяет различные активности и процессы для достижения результата.

Главная задача в этом измерении — устранение потерь (waste). Если в потоке есть шаг, который не добавляет ценности (например, лишнее согласование, которое никто не читает), его нужно убрать.

Внешние факторы: Модель PESTLE

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

* P (Political) — Политические: Законы, государственная стабильность, торговые ограничения. * E (Economic) — Экономические: Курсы валют, инфляция, экономический рост. * S (Social) — Социальные: Демография, образ жизни, отношение к технологиям. * T (Technological) — Технологические: Появление новых технологий (AI, 5G), которые меняют рынок. * L (Legal) — Правовые: Законы о труде, защите данных, интеллектуальной собственности. * E (Environmental) — Экологические: Климатические изменения, требования к «зеленым» технологиям.

Заключение

Четыре измерения управления услугами — это чек-лист для любого IT-руководителя. Запуская новую услугу или меняя старую, пройдитесь по списку:

Готовы ли Люди? Обучены ли они?

Есть ли подходящие Технологии?

Надежны ли Партнеры?

Выстроены ли Процессы и потоки работы?

Только баланс этих четырех элементов позволяет создавать устойчивую ценность. В следующей статье мы рассмотрим Сервисную систему ценности (SVS) — архитектуру, которая объединяет все эти компоненты в единую работающую систему.

Система ценности услуг (SVS) и семь руководящих принципов ITIL

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

Ответом на эти вопросы является Система ценности услуг (Service Value System — SVS). Это архитектурная основа ITIL 4, которая объясняет, как все компоненты и виды деятельности организации работают вместе как единое целое.

Что такое Система ценности услуг (SVS)?

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

В ITIL 4 такой «системой координации» выступает SVS. Главная задача SVS — обеспечить, чтобы организация постоянно создавала ценность для всех заинтересованных сторон через использование и управление продуктами и услугами.

Структура SVS

Система ценности услуг работает как преобразователь. На входе у нас есть Возможности (Opportunities) и Спрос (Demand), а на выходе — Ценность (Value).

!Структура Системы ценности услуг (SVS): преобразование спроса в ценность.

SVS состоит из пяти ключевых компонентов:

Руководящие принципы (Guiding Principles): Рекомендации, которые направляют организацию в любых обстоятельствах, независимо от изменений в целях или структуре.

Управление (Governance): Средства, с помощью которых организация управляется и контролируется (директивы, политики, правила).

Цепочка создания ценности услуг (Service Value Chain): Операционная модель, набор действий для создания конкретного продукта или услуги (об этом мы поговорим в следующей статье).

Практики (Practices): Наборы организационных ресурсов, предназначенные для выполнения работы или достижения цели (например, практика Service Desk или практика управления инцидентами).

Постоянное улучшение (Continual Improvement): Деятельность, направленная на то, чтобы услуги и процессы становились лучше с каждым днем.

Сегодня мы подробно остановимся на первом и, пожалуй, самом универсальном компоненте — Руководящих принципах.

Семь руководящих принципов ITIL

Руководящие принципы — это не жесткие правила, за нарушение которых штрафуют. Это философия, «компас», который помогает принимать правильные решения в сложных и неопределенных ситуациях. Они универсальны и применимы не только в IT, но и в любом бизнесе или даже в личной жизни.

ITIL 4 выделяет семь принципов. Рассмотрим каждый из них.

1. Фокусируйтесь на ценности (Focus on value)

Все, что делает организация, должно прямо или косвенно создавать ценность для заинтересованных сторон. Перед тем как начать любую задачу — будь то внедрение новой системы, написание кода или изменение процесса — задайте себе вопрос: «Как это поможет заказчику?».

Если действие не приносит ценности, его нужно либо изменить, либо прекратить.

Как применять: * Знайте, кто ваш потребитель (вспомните роли: Заказчик, Пользователь, Спонсор). * Понимайте, что именно они считают ценным (скорость? надежность? дешевизна?). * Фокусируйтесь на пользовательском опыте (CX/UX), а не только на технических параметрах.

> Не делайте работу ради работы. Делайте работу ради результата.

2. Отталкивайтесь от текущей ситуации (Start where you are)

Частая ошибка при трансформации — желание «снести все до основания и построить заново». Это дорого, рискованно и часто приводит к потере накопленных знаний.

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

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

3. Двигайтесь итеративно, используя обратную связь (Progress iteratively with feedback)

Не пытайтесь «съесть слона целиком». Грандиозные проекты, которые длятся годами без промежуточных релизов, часто заканчиваются провалом: пока вы их делаете, мир меняется, и результат становится никому не нужным.

Разбивайте работу на мелкие, управляемые части (итерации). После каждой итерации собирайте обратную связь от заказчика и корректируйте курс.

Как применять: * Используйте концепцию MVP (минимально жизнеспособный продукт). * Делайте маленькие шаги. Даже если шаг был ошибочным, исправить его дешевле, чем переделывать годовой проект. * Постоянно спрашивайте пользователей: «Это то, что вам нужно?».

!Итеративный подход позволяет корректировать курс и снижает риски.

4. Сотрудничайте и поощряйте прозрачность (Collaborate and promote visibility)

Мы уже говорили о вреде «информационных колодцев» (silos) в статье про четыре измерения. Когда люди скрывают информацию или работают изолированно, возникают ошибки и недопонимание.

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

Как применять: * Вовлекайте заказчиков и пользователей в процесс разработки, а не только в момент сдачи. * Делайте рабочие процессы видимыми (например, используйте Канбан-доски). * Делитесь информацией, даже если она неприятная (например, о сбоях).

5. Мыслите и работайте целостно (Think and work holistically)

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

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

Как применять: * Понимайте взаимосвязи. Если вы ускоряете разработку, справится ли с нагрузкой отдел поддержки? * Ищите баланс между всеми четырьмя измерениями.

6. Используйте простой и практичный подход (Keep it simple and practical)

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

Как применять: * Если шаг процесса не создает ценности — уберите его. * Используйте принцип Парето: 20% усилий дают 80% результата. * Начинайте с простого решения, усложняйте только при необходимости.

> Простота — это высшая степень изощренности.

7. Оптимизируйте и автоматизируйте (Optimize and automate)

Автоматизация — это мощный инструмент, но она должна применяться с умом. Существует золотое правило: никогда не автоматизируйте неэффективный процесс. Если вы автоматизируете хаос, вы получите «автоматизированный хаос».

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

Как применять: * Шаг 1: Оптимизируйте. Сделайте процесс максимально эффективным вручную. * Шаг 2: Автоматизируйте. Используйте технологии для рутинных, повторяющихся задач. * Оставьте людям задачи, требующие эмпатии, креативности и принятия сложных решений.

Взаимодействие принципов

Важно понимать, что эти принципы не изолированы друг от друга. Они работают вместе.

Например, вы хотите внедрить чат-бота для техподдержки:

Фокус на ценности: Поможет ли бот клиентам быстрее получать ответы?

Отталкивайтесь от текущей ситуации: Есть ли у нас база знаний, на которой бота можно обучить?

Оптимизируйте и автоматизируйте: Сначала наведите порядок в базе знаний (оптимизация), потом внедряйте бота (автоматизация).

Двигайтесь итеративно: Запустите бота сначала для одной темы (например, сброс пароля), соберите обратную связь, а потом расширяйте функционал.

Заключение

Система ценности услуг (SVS) — это «операционная система» ITIL 4, которая связывает все элементы воедино. Семь руководящих принципов — это универсальные ключи к принятию верных решений внутри этой системы.

Запомнив эти семь фраз, вы сможете ориентироваться в любых проектах по управлению услугами:

Ценность превыше всего.

Используй то, что есть.

Двигайся шагами.

Работай вместе.

Смотри на картину целиком.

Будь проще.

Сначала думай, потом автоматизируй.

В следующей статье мы заглянем в «сердце» SVS и разберем Цепочку создания ценности услуг (Service Value Chain) — модель, описывающую конкретные действия по созданию продуктов.

Цепочка создания ценности услуг (SVC): Шесть ключевых видов деятельности

Мы продолжаем наше путешествие по миру ITIL 4. В прошлой статье мы рассмотрели Систему ценности услуг (SVS) — глобальную архитектуру, которая превращает возможности и спрос в ценность. Мы сравнили её с заводом, где все компоненты (принципы, управление, практики) работают сообща.

Сегодня мы заглянем в самое сердце этого «завода». Мы изучим Цепочку создания ценности услуг (Service Value Chain — SVC). Если SVS — это сам завод, то SVC — это его производственная линия, операционная модель, которая определяет, какие именно действия нужно совершить, чтобы создать продукт или услугу.

Что такое Цепочка создания ценности услуг?

Цепочка создания ценности услуг (SVC) — это операционная модель, которая определяет ключевые виды деятельности, необходимые для реагирования на спрос и содействия созданию ценности посредством создания и управления продуктами и услугами.

Простыми словами, это набор «кубиков» (видов деятельности), из которых вы можете собрать любой процесс: от разработки нового приложения до замены картриджа в принтере.

Главное отличие ITIL 4 от предыдущих версий (где был жесткий жизненный цикл: Стратегия -> Проектирование -> Преобразование -> Эксплуатация) заключается в гибкости. В SVC нет строгого порядка. Вы можете комбинировать эти действия в любой последовательности.

!Структура Цепочки создания ценности услуг: шесть видов деятельности, преобразующих спрос в ценность.

SVC состоит из шести ключевых видов деятельности:

Планирование (Plan)

Улучшение (Improve)

Вовлечение (Engage)

Дизайн и преобразование (Design and Transition)

Получение / Создание (Obtain / Build)

Предоставление и поддержка (Deliver and Support)

Давайте разберем каждый из них подробно.

1. Планирование (Plan)

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

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

Примеры действий: * Стратегическое планирование развития IT-департамента. * Планирование портфеля услуг (какие услуги мы будем предоставлять в следующем году). * Планирование архитектуры и политик.

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

2. Улучшение (Improve)

Этот вид деятельности обеспечивает постоянное улучшение продуктов, услуг и практик во всех видах деятельности цепочки создания ценности и четырех измерениях управления услугами.

Цель: Сделать так, чтобы завтра мы работали лучше, чем сегодня.

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

Примеры действий: * Анализ метрик производительности. * Проведение ретроспектив после завершения проектов. * Внедрение автоматизации для рутинных задач.

3. Вовлечение (Engage)

Это «окно» вашей организации во внешний мир. Деятельность обеспечивает хорошее понимание потребностей заинтересованных сторон, прозрачность и постоянное взаимодействие.

Цель: Понять, что нужно заказчику, и поддерживать с ним связь.

Все, что касается коммуникации с пользователями, заказчиками, партнерами и поставщиками, проходит через этот блок.

Примеры действий: * Прием звонков в Service Desk. * Переговоры с заказчиком о требованиях к новому ПО. * Сбор обратной связи от пользователей. * Публикация новостей о плановых работах.

4. Дизайн и преобразование (Design and Transition)

Этот вид деятельности обеспечивает, чтобы продукты и услуги постоянно соответствовали ожиданиям заинтересованных сторон в отношении качества, затрат и времени выхода на рынок.

Цель: Спроектировать решение и подготовить его к использованию.

Здесь идеи превращаются в чертежи, а готовые компоненты собираются в работающую услугу. Важно отметить, что в ITIL 4 «Дизайн» и «Преобразование» (внедрение) объединены в один вид деятельности, чтобы избежать разрыва между «нарисовали на бумаге» и «запустили в продакшн».

Примеры действий: * Разработка архитектуры приложения. * Тестирование нового релиза. * Планирование развертывания обновления на серверы.

5. Получение / Создание (Obtain / Build)

Этот вид деятельности обеспечивает доступность сервисных компонентов тогда и там, где они нужны, и их соответствие согласованным спецификациям.

Цель: Добыть необходимые детали для услуги.

Здесь мы либо покупаем что-то готовое, либо создаем это своими руками. Это «технический цех» цепочки.

Примеры действий: * Написание программного кода разработчиками (Build). * Покупка серверов или лицензий у поставщика (Obtain). * Настройка облачной инфраструктуры.

6. Предоставление и поддержка (Deliver and Support)

Этот вид деятельности обеспечивает предоставление услуг и их поддержку в соответствии с согласованными спецификациями и ожиданиями заинтересованных сторон.

Цель: Обеспечить нормальную работу услуги для пользователя.

Это то, что пользователи видят каждый день. Это «фронтлайн» работающей услуги.

Примеры действий: * Решение инцидентов (починка того, что сломалось). * Выполнение запросов на обслуживание (выдача прав доступа, замена мышки). * Мониторинг доступности серверов.

Как это работает вместе: Потоки ценности

Самая большая ошибка — думать, что SVC работает линейно: 1 -> 2 -> 3... Это не так. SVC — это набор инструментов. В зависимости от задачи, вы выбираете нужные инструменты в нужном порядке. Этот конкретный путь через цепочку называется Потоком ценности (Value Stream).

Рассмотрим два примера, чтобы увидеть разницу.

Пример 1: Разработка новой фичи в приложении

Представьте, что пользователи попросили добавить «Темную тему» в ваше мобильное приложение.

Вовлечение: Менеджер продукта общается с пользователями, фиксирует потребность в темной теме.

Планирование: Команда оценивает трудозатраты и включает задачу в бэклог (план) следующего спринта.

Дизайн и преобразование: Дизайнеры рисуют макеты темной темы.

Получение / Создание: Разработчики пишут код (Build).

Дизайн и преобразование: Тестировщики проверяют сборку, DevOps-инженеры готовят релиз.

Предоставление и поддержка: Обновление становится доступным в App Store, пользователи скачивают его.

Улучшение: Команда анализирует отзывы: нравится ли пользователям новая тема?

Путь: Вовлечение -> Планирование -> Дизайн -> Создание -> Дизайн -> Предоставление -> Улучшение.

Пример 2: Покупка и установка нового принтера

В бухгалтерии сломался старый принтер, нужен новый.

Вовлечение: Бухгалтер звонит в Service Desk и сообщает о проблеме.

Предоставление и поддержка: Специалист поддержки диагностирует поломку, понимает, что ремонт невозможен.

Получение / Создание: Закупщик заказывает новый принтер у поставщика (Obtain).

Дизайн и преобразование: Принтер приезжает, админ настраивает его и подключает к сети.

Предоставление и поддержка: Бухгалтер начинает печатать.

Путь: Вовлечение -> Предоставление -> Получение -> Дизайн -> Предоставление.

!Визуализация того, как разные задачи формируют разные маршруты внутри Цепочки создания ценности.

SVC и методологии (Agile, DevOps, Waterfall)

Прелесть Цепочки создания ценности услуг в том, что она агностична к методологиям. Ей все равно, как вы работаете внутри кубиков.

* В блоке «Получение / Создание» вы можете писать код по Scrum, используя двухнедельные спринты, или использовать метод Waterfall для строительства дата-центра. * В блоке «Дизайн и преобразование» вы можете использовать DevOps-пайплайны для автоматического развертывания 10 раз в день или проводить ручное тестирование раз в месяц.

SVC дает структуру высокого уровня, позволяя вам наполнять её любыми современными практиками.

Заключение

Цепочка создания ценности услуг (SVC) — это универсальный конструктор для создания ценности. Она состоит из шести видов деятельности:

Планирование (куда идем?)

Улучшение (как стать лучше?)

Вовлечение (чего хочет заказчик?)

Дизайн и преобразование (как это будет работать и внедряться?)

Получение / Создание (где взять компоненты?)

Предоставление и поддержка (как это использовать?)

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

Обзор основных практик управления ITIL: От Service Desk до управления изменениями

Мы продолжаем наш курс по ITIL 4. В предыдущих статьях мы построили прочный фундамент: изучили Систему ценности услуг (SVS), рассмотрели Четыре измерения и разобрали Цепочку создания ценности (SVC). Если использовать аналогию со строительством, то SVS — это архитектурный план здания, SVC — это последовательность этапов строительства, а Практики управления — это инструменты и навыки, которые используют строители.

В ITIL v3 использовался термин «Процессы». В ITIL 4 мы говорим о «Практиках». Это важное изменение. Процесс — это просто последовательность действий. Практика же — это набор организационных ресурсов, предназначенных для выполнения работы или достижения цели. Практика включает в себя процессы, но также охватывает людей, технологии, партнеров и информацию (вспомните четыре измерения).

Всего в ITIL 4 существует 34 практики. Мы не будем разбирать их все, а сосредоточимся на самых важных — тех, с которыми любой IT-специалист сталкивается ежедневно.

!Практики ITIL как набор инструментов для выполнения работы.

1. Service Desk (Служба поддержки)

Многие ошибочно считают, что Service Desk — это просто колл-центр, где сидят люди в гарнитурах и говорят: «Попробуйте перезагрузить компьютер». В ITIL 4 роль этой практики гораздо шире.

Цель практики Service Desk — обеспечить единую точку контакта (Single Point of Contact — SPOC) между поставщиком услуг и пользователями.

Это «лицо» IT-департамента. От того, как работает Service Desk, зависит восприятие качества услуг пользователями. Даже если ваши серверы работают идеально (техническое качество), но оператор нагрубил пользователю или забыл перезвонить, клиент будет считать, что IT работает плохо.

Ключевые особенности современного Service Desk:

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

2. Управление инцидентами (Incident Management)

Это, пожалуй, самая известная практика. Что-то сломалось? Это инцидент.

Инцидент — это незапланированное прерывание услуги или снижение её качества.

Цель практики — минимизировать негативное влияние инцидентов путем скорейшего восстановления нормальной работы услуги.

Ключевое слово здесь — скорейшее. Задача управления инцидентами — не найти глубинную причину сбоя (этим занимается другая практика), а как можно быстрее «потушить пожар». Если сервер упал, приоритет инцидент-менеджера — поднять его или переключить на резервный, чтобы бизнес продолжил работать.

Роение (Swarming) против Эскалации

Традиционно используется уровневая поддержка (Tier 1, Tier 2, Tier 3). Заявка передается по цепочке вверх, пока не найдет специалиста. Это часто долго и создает эффект «пинг-понга».

ITIL 4 предлагает альтернативу — Роение (Swarming). Это подход, при котором группа специалистов с разными компетенциями собирается вместе сразу после возникновения сложного инцидента, чтобы коллективно найти решение. Это быстрее и эффективнее для сложных кейсов.

3. Управление проблемами (Problem Management)

Если управление инцидентами — это тушение пожара, то управление проблемами — это расследование причин возгорания и профилактика будущих пожаров.

Проблема — это причина одного или нескольких инцидентов.

Цель практики — снизить вероятность и влияние инцидентов путем выявления их фактических причин и управления обходными путями и известными ошибками.

!Различие между управлением инцидентами и управлением проблемами.

Три фазы управления проблемами:

Идентификация проблемы: Анализ трендов инцидентов. Например, если у пяти пользователей за неделю «вылетел» Outlook, это не пять случайных инцидентов, а одна проблема.

Контроль проблем: Анализ корневой причины (Root Cause Analysis). Здесь используются техники вроде «5 почему» или диаграммы Исикавы.

Контроль ошибок: Управление известными ошибками (Known Errors). Если мы нашли причину (баг в обновлении Windows), но не можем исправить её прямо сейчас (ждем патч от Microsoft), мы фиксируем это как «Известную ошибку» и создаем Обходной путь (Workaround).

> Обходной путь — это временное решение, которое позволяет восстановить услугу, пока полное исправление еще не найдено. Например: «Перезагружайте сервер каждые 24 часа, чтобы избежать утечки памяти».

4. Управление запросами на обслуживание (Service Request Management)

Не все обращения пользователей связаны с поломками. Иногда им просто что-то нужно: новый ноутбук, доступ к папке, справка 2-НДФЛ или замена картриджа.

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

Цель практики — поддерживать согласованное качество услуг путем эффективной обработки всех предопределенных, инициируемых пользователем запросов.

Главное отличие от инцидентов: запросы на обслуживание запланированы. Мы знаем, что они будут поступать, и заранее готовим для них алгоритмы.

Ключ к успеху здесь — стандартизация и автоматизация. Запрос на доступ должен проходить по четкому маршруту согласования, а не вызывать панику у админов.

5. Включение изменений (Change Enablement)

В ITIL v3 эта практика называлась «Управление изменениями» (Change Management). В ITIL 4 её переименовали в Change Enablement (Включение или Обеспечение изменений). Смена названия не случайна: слово «управление» часто ассоциировалось с бюрократией и замедлением. Новая цель — не тормозить изменения, а помогать им происходить быстро и безопасно.

Изменение — это добавление, модификация или удаление чего-либо, что может прямо или косвенно повлиять на услуги.

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

Три типа изменений

ITIL 4 выделяет три типа изменений, каждый из которых обрабатывается по-своему:

| Тип изменения | Описание | Пример | Как обрабатывается | | :--- | :--- | :--- | :--- | | Стандартное (Standard) | Низкий риск, часто повторяется, процедура хорошо известна и документирована. | Ежемесячная перезагрузка сервера, установка стандартного ПО. | Предварительно авторизовано. Не требует согласования каждый раз. | | Нормальное (Normal) | Изменение, которое требует оценки, авторизации и планирования. | Внедрение новой CRM-системы, переезд в новый офис. | Требует согласования. Уровень согласования зависит от риска (от тимлида до совета директоров). | | Экстренное (Emergency) | Изменение, которое нужно внедрить немедленно (обычно для устранения критического инцидента). | Установка патча безопасности при вирусной атаке. | Ускоренная процедура согласования, но документация оформляется постфактум. |

!Три типа изменений в ITIL 4.

6. Управление уровнем услуг (Service Level Management)

Эта практика связывает IT и бизнес языком цифр и ожиданий.

Цель практики — установить четкие цели для уровней услуг, основанные на бизнесе, и обеспечить, чтобы предоставление услуг оценивалось, контролировалось и управлялось в соответствии с этими целями.

Здесь мы встречаем понятие SLA (Service Level Agreement) — Соглашение об уровне услуг. Это документ, описывающий параметры услуги (время реакции, время доступности) и ответственность сторон.

Эффект арбуза (Watermelon Effect)

Одной из главных проблем традиционного SLA является «Эффект арбуза».

> Эффект арбуза — это ситуация, когда метрики SLA «зеленые» (формально все выполнено), но клиент «красный» (недоволен).

Пример: SLA требует доступности сервера 99,9%. Сервер был недоступен всего 10 минут за месяц (SLA выполнен, отчет зеленый). Но эти 10 минут пришлись на пик продаж в «Черную пятницу», и компания потеряла миллионы. IT-отдел требует премию за выполнение KPI, а бизнес в ярости.

ITIL 4 призывает переходить от чисто технических метрик к метрикам, отражающим реальный опыт пользователя (XLA — Experience Level Agreement).

7. Управление релизами (Release Management)

Часто путают с управлением изменениями или развертыванием. Давайте разберемся.

Релиз — это версия услуги или элемента конфигурации, которая становится доступной для использования.

Цель практики — сделать новые и измененные услуги и функции доступными для использования.

В современном мире (DevOps, Agile) релизы часто происходят автоматически и очень часто. Разница между «Развертыванием» (техническая установка кода на сервер) и «Релизом» (открытие доступа пользователям) становится критичной. Вы можете развернуть код на сервере (Deployment), но скрыть его за «фича-флагом», и включить для пользователей (Release) только через неделю.

Взаимосвязь практик

Важно понимать, что эти практики не работают в вакууме. Рассмотрим типичный сценарий:

Пользователь звонит в Service Desk (у него не работает программа).

Оператор регистрирует Инцидент.

Выясняется, что программа не работает из-за бага после обновления. Инцидент передается в Управление проблемами.

Для исправления бага нужно накатить патч. Создается запрос на Изменение.

Патч проходит тестирование и оформляется в Релиз.

После установки патча инцидент закрывается, а пользователь получает уведомление.

Заключение

Мы рассмотрели семь ключевых практик ITIL 4. Это «джентльменский набор» для управления IT-услугами. Конечно, практик гораздо больше (управление активами, управление информационной безопасностью, управление архитектурой и т.д.), но понимание именно этих основ позволяет выстроить стабильную и предсказуемую работу IT-департамента.

Главное, что нужно запомнить: практики — это не бюрократические барьеры, а инструменты, помогающие создавать ценность. Если практика мешает работе и не приносит пользы — вспомните руководящий принцип «Фокусируйтесь на ценности» и измените её.

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