Профили

Андрей Сафонов: Применяя ITSM, трудно что-то сделать неправильно

Интеграция Внедрения
мобильная версия

Большинство западных ИТ-компаний давно применяют в своей практике рекомендации ITSM. Однако в России европейская и американская экспертиза в этой области пока не прижилась в полной мере. О том, почему так происходит и что надо делать, чтобы ситуация изменилась, размышляет исполнительный директор компании iCore Андрей Сафонов.

Можно посмотреть на тему внедрения ITSM со стороны «эффективного менеджера»: в случае правильно построенного сервиса не только обеспечено бесперебойное функционирование всех систем, а дополнительно имеется понимание того, какое количество ресурсов требуется для того, чтобы и дальше все было хорошо. И пойти к руководству просить денег гораздо проще с листочком бумаги, на котором расписано, сколько и какого оборудования когда надо купить.

CNews: С каким трудностями сталкиваются компании, решившие применять рекомендации ITSM?

Андрей Сафонов: В России? Я считаю, что это не структурированный бизнес и недостаточное вовлечение руководителей ИТ в бизнес. Инициатива по внедрению ITSM обычно исходит от ИТ. Вы, как ответственный за сервис, пытаетесь наложить процессные методы управления на бизнес, в котором нет формализованных процессов. У вас ничего не получается, а вы не обладаете достаточным авторитетом, чтобы «продавить» бизнес-руководство и внести изменения – не в ИТ, а в бизнес. На этом все заканчивается.

CNews: Какие ошибки совершают компании, решившие воспользоваться рекомендациями ITSM?

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

CNews: Какие преимущества появляются у компании, использующей в работе процессинговое управление?

Андрей Сафонов: Мне кажется, что главное преимущество в том, что появляются критерии объективной оценки качества работы ИТ-подразделения. Да, конечно, основной показатель уровня сервиса — это удовлетворенность бизнес-пользователя. А на основании каких критериев ее оценивает бизнес? Чаще всего субъективно. Если нет измеряемых критериев оценки качества работы сервиса ИТ, то невозможно сказать, почему он работает плохо (или хорошо): то ли потому, что ИТ не умеет (умеет) организовать сервис, то ли потому, что у ИТ недостаточно (много) ресурсов. Процессинговое управление, даже в зачаточном состоянии, позволяет оценить, где работа организована хорошо, а где плохо — вместо того, чтобы мерить среднюю температуру по больнице.

CNews: Какие параметры прописываются в SLA у системных интеграторов и по каким параметрам должны оцениваться ИТ-подразделения?

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


Процессинговое управление позволяет оценить, где работа организована хорошо, а где плохо

Во-первых, есть такое понятие, как время реакции. Есть заявка от клиента (не важно, как она поступила — по электронной почте, в систему регистрации заявок, по телефону или иначе), и она должна попасть в систему сопровождения заявок. И заказчик должен через обозначенное время получить ответ: «Ваша заявка принята, работа начата». Это мы сейчас говорим про Service Desk, с внедрения которого начинается внедрение ITSM. Я сейчас просто процитировал ITIL, дальше попробую сам подумать.

Во-вторых, каждый запрос на обслуживание имеет свой уровень критичности, который определяет время реакции. Это и есть SLA. Если это запрос на смену картриджей, то время реакции может быть Next Business Day. Если это заявка, которая может вызвать стоп-бизнес, то время реакции может быть сокращено до минут.

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

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

Список SLA можно придумать длинный. К примеру, возникают вопросы BCP и BCM: «железо» требует периодических остановок для профилактики, программы требуют периодических обновлений, а бизнесу нужна система, которая работает онлайн 365 дней в году, 7 дней в неделю, 24 часа в сутки. Что может служить критерием качества работы ИТ-сервиса в этом аспекте? На мой взгляд, только допустимое время простоя системы. Не аварийного простоя, а разрешенного времени остановки системы для обслуживания. Например, 10 дней в году или 10 минут в год.

Я сейчас пытаюсь пересказывать ITIL, вряд ли это имеет смысл, оригинал интереснее.

CNews: А если говорить о внутренних SLA?

Андрей Сафонов: Не имеет значения, внутренние SLA или внешние. Если SLA формализованы, их приходится соблюдать.

Полина Осокина