Процессы поддержки услуг

Записаться

Процессы поддержки услуг

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

Служба Service Desk (service desk) здесь отдельно не рассматривается. Основное внимание уделяется управлению инцидентами, проблемами, конфигурациями, изменениями и релизами.

Управление инцидентами

Управление инцидентами (incident management) — один из самых известных процессов. Его логика отвечает на вопрос: что делать, если в ходе нормального оказания услуги произошёл сбой, ошибка или пользователь сделал что-то неправильно?

Ответ разделяется на две задачи.

1. Что делать прямо сейчас? Нужно как можно скорее восстановить нормальное оказание услуги. Для этого могут использоваться резервные мощности, сохранённые данные и другие доступные средства. Цель — быстро переключиться, восстановить данные и вернуть работоспособность услуги.
2. Что делать потом? Поиск причины инцидента не является срочной задачей. Он может занять месяцы. Пока причина не найдена, инцидент может повторяться, и каждый раз придётся снова восстанавливать услугу.

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

Управление проблемами

Управление проблемами (problem management) — отдельный процесс. Он идёт медленно, и его основная цель — не быстрое выполнение, а хорошее разбирательство в ситуации.

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

Управление конфигурациями

Управление конфигурациями (configuration management) — фундаментальный процесс. Чтобы разрешать инциденты и искать проблемы, нужно располагать информацией о том, что есть в инфраструктуре и что именно сломалось.

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

Это же описание конфигурации частично используется управлением мощностями (capacity management): активы и компоненты из описания закупаются, мониторятся и выводятся из эксплуатации.

Управление изменениями

Управление изменениями (change management) — очень важный и сложный процесс. Строго говоря, он не является специфичным только для управления услугами. В идеале на предприятии должен быть общекорпоративный процесс управления изменениями: в оборудовании, персонале, бизнес-процессах, корпоративной информации и других доменах бизнес-архитектуры.

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

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

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

Управление релизами

Управление релизами (release management) похоже на управление изменениями, но немного про другое. Оно упорядочивает работу по подготовке новых версий продукта, услуги или разработки.

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

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

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

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

Процессы, оставшиеся в стороне

Два процесса остались несколько особняком.

1. Управление информационной безопасностью (information security management).
2. Управление взаимоотношениями с заказчиком (customer relationship management). Оно не выделено в отдельную активность, но элементы таких взаимоотношений есть в разных процессах. Например, в управлении уровнем обслуживания есть анализ требований, обсуждение услуги и подготовка.

Краткие итоги

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

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

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

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

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