03.11.2008 Intelligent Enterprise

Внедрение SLM. Сервисные отношения с бизнесом

В финансовой корпорации УРАЛСИБ завершен проект внедрения процесса управления уровнем сервисов (Service Level Management — SLM). Об организации работ по проекту и о том, как в результате изменился каталог услуг и процессы управления инцидентами, изменениями и конфигурациями, уже существовавшие в корпорации, в интервью нашему журналу рассказал заместитель главного исполнительно директора главной исполнительной дирекции ИТ Андрей Мирянович Нарсия.

Intelligent Enterprise: Давайте начнем с организационных вопросов. Сколько времени заняло внедрение? На какие этапы делился проект и кто выступал его исполнителем?

Андрей Нарсия: Проект был начат в сентябре 2007. Мы предполагали завершить его к январю 2008, но окончательно закрыли проект только в мае. Сначала было проведено концептуальное проектирование, в ходе которого определились основные реперные точки процесса SLM, концепция изменения каталога услуг и формирования соглашений об уровнях сервисов. Затем мы перешли к детальному проектированию, детализации процедур процесса, определению того, как маршрутизируются запросы. Например, на этапе концептуального проектирования была отвергнута роль account manager-а, человека, который отвечает за взаимодействие с конкретным бизнес-подразделением, выступает посредником между нами. Но позже, при детальном проектировании выяснилась крайняя необходимость такой роли, и она была возвращена.

Форма работы над проектом была не вполне стандартной. Основным исполнителем работ, проектировщиком выступила компания «ИНЛАЙН ГРУП», а на роль независимого аудитора были приглашены специалисты компании IT Expert. Мы совершенно осознано хотели сотрудничать именно с двумя организациями, исходя из своего прошлого опыта. У нас в предыдущем проекте по внедрению процессов ITSM уже участвовало две команды с очень похожим разделением ролей. Подобная связка показала свою эффективность и в этот раз мы решили воспользоваться той же схемой. Если между нами, т.е. заказчиком и исполнителем возникали споры, то аудиторы выступали третейским судьей. Это реально работало. Формально аудиторы находились на субподряде у исполнителей.

Какова была ситуация с управлением ИТ-услугами в корпорации до начала проекта?

Еще до начала проекта внедрения SLM у нас существовали процессы управления инцидентами, изменениями и конфигурациями. Параллельно с SLM внедрялось управление проблемами. Можно сказать, что до того полноценно работал только процесс управления инцидентами, т.к. управление изменениями функционировало в усеченном виде, а управление конфигурациями до появления SLM работал в режиме накопления информации, т.к. выходом для этого процесса по большей части должен был стать процесс управления уровнем сервисов. Существовавший каталог услуг формировался исходя из его понимания ИТ-специалистами. В нем еще не было разделения на бизнес- и поддерживающие услуги. Одна из задач проекта как раз состояла в построении сервисно-ресурсной модели, увязке услуг с теми ресурсами, на которые они опираются. В ходе проекта каталог услуг был переструктурирован. Надо сказать, что желание переделать каталог услуг возникло у нас уже давно. Но, чтобы не заниматься изменением каталога услуг дважды, мы специально ждали момента, когда начнем формировать соглашения об уровне сервиса (SLA). Мы хорошо понимали, что в ходе этой работы откроются вещи, которые до того мы не смогли бы учесть. Как оказалось, мы были совершенно правы, оттягивая почти на год внесение изменений в каталог услуг. В итоге уже на этапе концептуального проектирования мы сформировали требования для нового каталога сервисов и многие из них действительно сильно отличались от того, как нам виделось ранее.

С какими бизнес-подразделениями вы решили заключать SLA в первую очередь и с какими заключите в дальнейшем в ходе масштабирования процесса?

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

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

Какие именно изменения произошли в каталоге услуг и как вы планируете поддерживать его в актуальном состоянии?

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

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

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

Какие уровни сервисов у вас существуют?

Сначала было запланировано три уровня, но потом мы увидели, что все подразделения из пилотной зоны выбрали максимально высокий уровень сервиса. Причем не очень обоснованно, заказчики просто взяли все по максимуму. По нашим ощущениям подразделения оказались не готовы к тому, чтобы правильно оценить нужный им уровень сервиса. Тогда мы «схлопнули» предложение до некоторого единого среднего уровня. На сегодня по факту уровень предоставления сервисов один. Через некоторое время, когда к бизнес-подразделениям придет понимание, будем расширять их число. В требованиях к уровню сервиса (SLR) мы зафиксировали эти потребности и будем готовы вернуться к этому вопросу через определенное время в рамках процедуры совершенствования процесса.

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

Какая отчетность формируется по процессу SLM?

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

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

Что обязательно должно быть готово для начала работы над процессом SLM?

Обязательно должна быть организована служба Service Desk, внедрен процесс управления инцидентами, изменениями и конфигурациями. Это минимальный набор, который должен быть. Параллельно появившийся у нас процесс управления проблемами на данном этапе на внедрение SLM не повлиял.

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

Новости
  • 26.09.2017
    «ИНЛАЙН ГРУП» и Fortinet защитили web-сервисы ТМК Подробнее
  • 14.09.2017
    «ИНЛАЙН ГРУП» на III Федеральном ИТ-форуме нефтегазовой отрасли России Подробнее
Проекты
  • Альфа-Банк
    Консолидация ИТ-ресурсов на основе индустриальных стандартов