Предыдущая часть 4. Передать и Эвакуироваться (Service Transition) Передача сервиса в эксплуатацию должна обеспечивать контролируемый переход от разработки или изменения к реальной работе. Здесь должны быть тестирование, управление изменениями, релизами, знаниями, конфигурациями и готовностью поддержки. На практике ITSM-передача сервиса в эксплуатацию часто выглядит как момент, когда все участники медленно отходят от “объекта” и надеются, что он не взорвётся до отчётного периода премирования. Формально всё красиво: * есть изменение; * есть план внедрения; * есть окно работ; * есть чек-лист; * есть ответственные; * есть план отката. На практике это может означать, что сервис был выведен в продукт в пятницу вечером, потому что «так было нужно бизнесу», а поддержка узнала об этом из обращения пользователя. ПЭ - это фаза, на которой сервис перестаёт быть проектной проблемой и становится эксплуатационной радостью. Особенно ценен момент передачи знаний. Обычно он состоит из встречи на тридцать минут и фразы: «Если что, пишите в личку». И то самое «если что» наступает сразу по окончании рабочего дня.

5. Это Сломалось (Service Operation) Эксплуатация сервиса в ITSM нужна для стабильного предоставления услуги пользователям. Здесь живут инциденты, запросы, проблемы, события, поддержка и всё то, что пользователи считают ИТ, а ИТ считает ежедневным наказанием за чужие грехи и архитектурные решения. Сервис уже работает. Пользователи привыкли. Бизнес зависит. Значит, любые изменения становятся потенциальной угрозой. Теперь главная задача - поддерживать сервис, чинить его, защищать от лишних движений и по возможности не задавать вопрос, почему он вообще был сделан именно так. На этом этапе особенно ярко проявляется магия ITSM. Инцидент закрывается, потому что работоспособность восстановлена. Проблема остаётся, потому что причина требует времени. Изменение откладывается, потому что риск заруинить связанные сервисы. Риск вшит в монолитную конструкцию и становится ограничением в правилах использования сервиса. Пользователь получает ответ, что обращение зарегистрировано и будет решено в обозримом столетии. ЭС - это зона, где сервис официально жив, но его жизнь поддерживается за счёт дежурств, костылей, неформальных договорённостей, памяти инженеров и священного легаси. Сервис должен оставаться в живых как можно дольше, чтобы обеспечить финансовую отдачу и необходимый объём работы всем участникам. А если он работает плохо, это не всегда повод его менять. Иногда это повод обновить метрику.

6. Постоянно Улучшаем видимость (Continual Improvement) Постоянное улучшение в ITSM должно помогать системно находить слабые места, повышать качество сервисов, снижать риски, устранять причины проблем и делать процессы полезнее. На практике ITSM-постоянное улучшение нужно для того, чтобы руководство, аудиторы и сотрудники, занятые измерением и оценкой сервиса, чувствовали себя счастливыми. Для этого сервис регулярно оценивается, обсуждается, измеряется и отображается в отчётах. Метрики позволяют показать управляемость. Дашборды позволяют показать прозрачность. Совещания позволяют показать вовлечённость. А если всё это не помогает улучшить сервис, то хотя бы создаёт устойчивое ощущение, что процесс под контролем. ПУ - особенно хорошо проявляется в ситуациях, когда после крупного сбоя собирается рабочая группа, формируется план корректирующих мероприятий, назначаются ответственные, идет бурная деятельность, проводится встреча по итогам, а через месяц другой проблема повторяется почти в том же виде, но уже с обновлённой причиной.

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