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

Новый сервис - это изменение. Изменение - это риск. Риск - это ответственность.

Ответственность - это то, что в зрелых процессах должно быть аккуратно распределено между всеми участниками так, чтобы в случае проблемы виноватым оказался никто конкретный. В случаях, когда сервис всё же достигает пользователей, акценты меняются на противоположные. Сервис должен оставаться в живых как можно дольше, чтобы обеспечить финансовую отдачу и необходимый объём загрузки персонала. Цель при этом остаётся прежней: минимизация изменений. Пять этапов мёртвого цикла ITSM Мёртвый цикл ITSM на практике состоит из пяти областей, основанных на реально существующих понятиях ITSM и ITIL, просто прошедших через мясорубку реальной эксплуатации.

1. Сначала Согласуем (Service Strategy) Стратегия в классическом ITSM должна определять, зачем сервис нужен, какую ценность он создаёт, какую потребность бизнеса закрывает и как его развитие связано с целями организации. На практике ITSM-стратегия начинается тогда, когда бизнес приходит с потребностью, которую почему-то нельзя просто проигнорировать. После этого начинается движение: * выяснение требований; * поиск ответственных; * проверка ограничений; * обсуждение рисков; * попытка понять, можно ли решить вопрос без появления нового сервиса. Планирование существует, но в основном как ретроспективный жанр. Сначала что-то происходит. Потом под это подбирается объяснение. Потом появляется документ, в котором написано, что именно так всё и планировалось.

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

2. Убедиться, что Страдают (Demand Management) Управление спросом в ITSM должно помогать понимать потребности бизнеса, прогнозировать нагрузку на сервисы и балансировать возможности ИТ с ожиданиями потребителей. На практике ITSM-управление спросом работает как фильтр страдания. Сервис появляется не потому, что организация заранее осознала его ценность, а потому что давление стало достаточно сильным. Бизнес просит. Потом просит еще раз. Потом назначает ответственного. Потом начинается совещание. Потом появляется ощущение, что, возможно, потребность действительно существует. В этот момент процесс начинает работать как положено: * уточнить; * согласовать; * переоформить; * вернуть; * снова уточнить; * запросить обоснование; * попросить экономический эффект; * отправить на доработку; * назначить встречу через неделю. Формально это управление спросом. На практике - способ убедиться, что бизнес действительно достаточно страдает, чтобы продолжать. УС позволяет отделить случайные инициативы от настоящих потребностей. Настоящая потребность - это такая хотелка, которая пережила три возврата инициативы, двадцать два совещания и один комментарий в стиле «нужно более детально описать бизнес-эффект».

3. Причесать Стихийное (Service Design). Проектирование сервиса в нормальном ITSM нужно для того, чтобы заранее продумать архитектуру, уровни сервиса, поддержку, безопасность, мощность, доступность, непрерывность, поставщиков и прочие скучные вещи, без которых сервис потом обычно горит. На практике ITSM-проектирование начинается с вопроса: «А почему оно уже работает?» На этом этапе сервис пытаются поместить в понятные рамки. Выясняется, что владелец не назначен, документация частично есть в переписке, SLA подразумевалось устно, поддержка держится на одном инженере, а интеграция сделана «временно», то есть навсегда. Контроль начинается с простых вопросов: * что это; * кто владелец; * где документация; * кто поддерживает; * почему оно уже работает. Если рамки не подходят, это проблема сервиса, а не рамок. ПС - это искусство взять стихийно возникшую конструкцию, назначить ответственных и сделать вид, что теперь она стала управляемой. Продолжение