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

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

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

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

На какие этапы делился проект внедрения процесса SLM и как вы его организовали?

Проект был начат в сентябре 2007 года. Мы предполагали завершить его к январю 2008‑го, но окончательно закрыли только в мае. Сначала было проведено концептуальное проектирование, в ходе которого определились реперные точки процесса SLM, концепция изменения каталога услуг и формирования соглашений об уровнях сервисов. Затем мы перешли к детальному проектированию, описанию процедур процесса, определению того, как маршру­тизируются запросы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А как вы определяли их стоимость?

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

Когда с вашей точки зрения можно приступать к внедрению процесса SLM? И как изменились уже существующие процессы управления инцидентами, изменениями и конфигурациями?

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

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