Проект

Уралсиб ФК (HP OpenView Service Desk)

Заказчики: Уралсиб ФК

Москва; Финансовые услуги, инвестиции и аудит

Продукт: HP OpenView Service Desk
На базе: HPE OpenView

Дата проекта: 2005/04
Технология: ITSM - Системы управления IT-службой
подрядчики - 244
проекты - 1453
системы - 587
вендоры - 328

В 2005 году руководством главной исполнительной дирекции по информационным технологиям было принято стратегическое решение о переходе к управлению ИТ-услугами. В качестве инструмента автоматизации ИТ-операций была выбрана платформа HP OpenView Service Desk 4.5. Силами различных поставщиков удалось развернуть несколько ITSM-процессов. К 2007 году были внедрены процессы управления инцидентами, изменениями, конфигурациями, проблемами, функционировала централизованная служба поддержки пользователей Service Desk с ИТ-специалистами в Москве и Уфе — в этих городах расположены самые крупные площадки финансовой корпорации. Также имелся каталог сервисов, реализованный по одноуровневой архитектуре и представляющий собой список из 866 позиций. «Работать с ним было крайне неудобно, поскольку удержать в голове столько сервисов координаторам службы поддержки пользователей Service Desk было крайне непросто», — вспоминает Юрий Салихов, менеджер процесса управления уровнем сервиса главной исполнительной дирекции информационных технологий банка «Уралсиб».

С помощью HP OpenView Service Desk 4.5 менеджеры процессов и сервисов анализировали статистику фактических показателей ИТ-сервисов. Одновременно проводилось анкетирование пользователей, на основании результатов которого формировались критерии их удовлетворенности качеством ИТ-сервисов.

Несмотря на то что целый ряд ITSM-процессов уже был развернут, множество острых вопросов, касающихся взаимодействия бизнеса и ИТ, оставались нерешенными. Например, бизнесу по-прежнему было непонятно, за что именно он платит деньги, почему именно столько, насколько это оправданно, да и вообще так ли нужен тот или иной сервис, который предоставляет ИТ-служба, и кто и за что в ней отвечает? В свою очередь, ИТ-служба продолжала искать ответы на свои вопросы: что на самом деле бизнес ждет от ИТ, нужны ли бизнесу те или иные ИТ-сервисы, соответствует ли качество сервисов требуемому бизнесу уровню и пр. Все эти вопросы стали основой для формирования требований к новому проекту по развертыванию процесса управления уровнем обслуживания (Service Level Management, SLM).

Исполнителем проекта внедрения SLM была выбрана компания «Инлайн Груп», в качестве независимого аудитора проекта — компания ITExpert.

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

В начале проектирования были определены роли, которые будут задействованы в данном процессе. «Уже после завершения проектирования возникла необходимость введения двух новых важных ролей, — вспоминает Боганов Андрей, директор департамента ITSM-решений компании “Инлайн Груп”, руководитель проекта со стороны компании-исполнителя. — Во-первых, появилась роль менеджера сервиса — ИТ-сотрудника, отвечающего за работоспособность и параметры предоставления данного сервиса, а во-вторых, появилась роль аккаунт-менеджера — сотрудника ИТ-службы, отвечающего за взаимодействие с конкретным бизнес-заказчиком (эта роль не описана в книгах ITIL, она предполагает единую точку контакта ИТ-службы с бизнес-заказчиком): за согласование набора и параметров ИТ-сервисов, которые должны предоставляться данному бизнес-заказчику, за подписание требований к уровню обслуживания (Service Level Requirements, SLR), за соглашения об уровне обслуживания (Service Level Agreement, SLA), а также за финансовые взаимоотношения. Идея была в том, что SLM в дальнейшем должен был стать формальной основой финансовых отношений бизнеса и ИТ-службы».

Для интеграции процесса SLM с уже внедренными ITSM-процессами пришлось модифицировать структуру базы данных CMDB и существенно изменить процесс управления инцидентами. Был кардинальным образом перестроен каталог сервисов. «Мы создали трехуровневую модель сервисов, — говорит Салихов. — Заказчику нужен конечный результат — надежные и доступные ИТ-сервисы, и ему неинтересно, какие инфраструктурные сервисы задействованы для их оказания, какими характеристиками обладают эти инфраструктурные сервисы и какие специалисты участвуют в процессе их предоставления (это станет интересным для заказчика на этапе анализа формирования стоимости и тарифов ИТ-сервисов). Исходя из этого, мы определили бизнес-сервисы (сейчас их 67) и бизнес-подсервисы (их 148) — это те ИТ-сервисы, которые предоставляются нашим бизнес-заказчикам. Кроме того, были определены и внутренние сервисы (их около 50), в отличие от первых двух групп, они не предоставляются бизнес-заказчикам напрямую, но непосредственно влияют на оказание бизнес-сервисов и бизнес-подсервисов». В соглашениях SLA, которые заключались с заказчиками, фигурировали только первые две группы сервисов.

Были определены и прописаны взаимосвязи ИТ-сервисов друг с другом. Существенной коррекции подвергся процесс управления изменениями. Для обкатки новой концепции управления уровнем сервиса были выбраны пилотные сервисы в Москве и Уфе, причем в этих двух городах это были разные бизнес-заказчики.[1]

Примечания