ITIL вне ИТ и почти без процессов

Как правило, внедрение ITIL начинается с процессов управления инцидентами и проблемами, заключения SLA и прочих «процессных» вещей. И в большинстве случаев участникам проекта удается «согреться» в процессе, однако радикального улучшения взаимопонимания между бизнесом и ИТ-службой не происходит. Почему?

Причины, почему внедрение ITIL в ИТ не дает результатов, по моему мнению, таковы.

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

Таким образом, внедрять ITIL нужно в компании в целом, и начинать нужно с идеологии, а не с процессов. Обычно внедрение ITIL начинается с процессов управления запросами на обслуживание, инцидентами и проблемами, что позволяет структурировать взаимодействие с пользователями и получить представление о ситуации внутри ИТ, но слабо помогает в главном — выстраивании взаимоотношений с бизнесом на основе сервисного подхода. Что касается внедрения внутри ИТ, то это скорее отталкивает бизнес, чем помогает говорить с ним на одном языке.

В финансовой группе «БКС», в которой мне довелось работать в должности начальника управления системы менеджмента качества, стояла задача внедрения полноценной системы управления качеством, одним из элементов которой должна была стать система управления услугами. Компания приняла новую стратегию, согласно которой, в частности, изменилась ее организационная структура: было образовано несколько независимых направлений бизнеса и создан общий операционно-вспомогательный блок для обслуживания всех этих направлений. Реорганизация потребовала внедрения нового подхода к налаживанию взаимодействия между подразделениями — таким подходом стало управление внутренними услугами. В первую очередь речь шла о взаимодействии бизнеса с подразделениями, не зарабатывающими деньги напрямую: это финансовый блок, ИТ-служба, юристы, бэк-офис и т. п. Однако операционные и вспомогательные подразделения тоже оказывают услуги друг другу (например, управление персоналом подбирает кадры для юристов, ИТ-отдел поддерживает системы бэк-офиса и т. п.), и это было учтено в разработанной модели.

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

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

• создание концепции управления внутренними услугами и ее активное разъяснение сотрудникам, начиная с высшего менеджмента;
• создание каталога услуг;
• введение регулярной процедуры опроса заказчиков по удовлетворенности услугами, которые им предоставляются, с привязкой бонусов руководителей и сотрудников подразделений-подрядчиков к удовлетворенности заказчиков услуг;
• заключение SLA с формализацией требований к услугам;
• переход от субъективной оценки качества (через опросы) к объективной (через измерение показателей из SLA).

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

Концепция

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

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

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

Каталог услуг

Каталог был разработан в первой половине 2011 года примерно за три месяца, из которых основное время ушло на согласование и утверждение. В проекте участвовали бизнес-технологи и представители всех подразделений компании. Работа над каталогом не была разовой акцией — каталог обновляется ежеквартально, а также по мере необходимости.

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

В текущей версии каталога услуг на его первом уровне находятся подразделения компании, оказывающие услуги, — например, департамент обслуживания клиентов, юридическая дирекция, дирекция по управлению персоналом, дирекция по ИТ. На втором уровне расположены конкретные услуги. Для дирекции по ИТ введено деление на услуги для конечных потребителей («Формирование корпоративной отчетности», «Расчет заработной платы» и т. д.) и системные услуги («Глобальная (корпоративная) сеть», «Система мониторинга состояния серверов»). Системные услуги сгруппированы вокруг конечных услуг. Для остальных подразделений в каталоге содержатся только услуги для конечных потребителей, поскольку их организационная структура не столь сложна, как у ИТ-дирекции, — в рамках этих подразделений нет «внутренних поставщиков», которые не работали бы напрямую на заказчиков.

Услуги ИТ-дирекции в основном сгруппированы относительно приложений, но если приложение поддерживает несколько бизнес-процессов, то услуги тоже группируются относительно них. У остальных подрядчиков услуги группируются по бизнес-процессам. Группировать услуги относительно обслуживаемых подразделений нет смысла, поскольку одна и та же услуга часто оказывается многим подразделениям. При формировании каталога внимание уделялось в первую очередь тому, чтобы наименования услуг были понятны заказчикам, услуги не дублировались и не были слишком мелкими, например: эквайринговое обслуживание (дирекция по ИТ), обеспечение платежей и расчетов (дирекция по ИТ), проверка договоров (юридическая дирекция), формирование/согласование доверенности (юридическая дирекция), управленческая отчетность (финансовая дирекция), оформление выписок, справок, копий кадровых документов (дирекция по управлению персоналом).

При задании услуг в каталоге используются в основном стандартные атрибуты: наименование услуги, ее описание, требования потребителей в формате KPI, заказчик услуги, ее владелец, методологи (сотрудники, отвечающие за разработку и внедрение процессов оказания услуги), а также ответственный за поддержку (тот, кто обрабатывает инциденты по услуге). Относительно оригинальным является атрибут услуги, фиксирующий принадлежность услуги к текущей деятельности или к развитию. Под текущей деятельностью понимается регулярная работа, а под развитием — изменение существующих процессов, систем или услуг. Например, развитие — это разработка/изменение процессов предоставления услуги и продуктов брокера, разработка/изменение процессов депозитария, разработка сайтов, подготовка и проведение продуктовых рекламных кампаний; текущая деятельность — валютный контроль, отправка и прием рейсов платежей, организация уборки помещений, управление закупками.

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

Рис. 1. Титульная страница каталога услуг

Оценка удовлетворенности

Процедура оценки удовлетворенности услугами включает в себя несколько этапов.

• Cамооценка подрядчика: за 10 дней до конца квартала руководители — владельцы услуг (руководители подразделений) оценивают себя сами, дополняя оценку ее обоснованием.
• Oценка заказчика: в течение 15 дней в начале квартала заказчики услуг (тоже руководители) оценивают качество предоставленных услуг с обязательным обоснованием, если оценка ниже 5.
• Урегулирование разногласий, расчет KPI: в течение 5 дней после выставления оценки подрядчик может обсудить с заказчиком спорные оценки, заказчик может внести изменения в свою анкету. Если прийти к консенсусу не удается, вопросы выносятся на комитет. По итоговым оценкам сводятся KPI подразделений подрядчиков и передаются в отдел кадров и бухгалтерию для расчета и выплаты премий.
• Подготовка и утверждение корректирующих мероприятий: в течение 15 дней после расчета KPI подрядчики обязаны разработать, согласовать с заказчиками и предоставить перечень корректирующих мероприятий по каждой услуге, по которой были получены оценки ниже 5.

На рис. 2 приведена выдержка из реального протокола оценки удовлетворенности клиентов.

Рис. 2. Пример протокола оценки удовлетворенности

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

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

SLA

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

Объективное измерение качества

По этому направлению ожидания сильнее всего разошлись с реальностью. Оказалось, что многие заказчики и подрядчики не стремятся уйти от неопределенности и субъективизма в оценке качества услуг — их устраивает оценка по школьной шкале без измерения реальных показателей. Большинство вспомогательных подразделений, не участвующих напрямую в клиентских бизнес-процессах, остановились именно на субъективной форме оценки качества предоставляемых услуг. Безусловно, есть заказчики, способные установить выраженные в цифрах требования и заинтересованные в получении фактических данных по соответствию реальности зафиксированным нормативам. В первую очередь это касается процессов обслуживания клиентов, где задержки или ошибки непосредственно влияют на удовлетворенность потребителей. В частности, в контактном центре, в офисах обслуживания все операции регламентированы, установлены нормативы по срокам и надежности, регулярно проводится измерение фактического состояния процессов. Конечно, понадобилось внедрение некоторых процессов управления услугами по рекомендациям ITIL, но при этом не только на уровне ИТ, но и на уровне всех внутренних услуг в компании были развернуты следующие процессы: управление каталогом услуг; управление запросами на обслуживание; управление инцидентами; управление проблемами; заключение SLA. Формализация этих процессов помогает поддерживать систему управления качеством и иметь представление о ее состоянии. Но без «топлива», которым служит мотивация на постоянное улучшение услуг и удовлетворение требований заказчика, этот двигатель не будет тянуть машину компании вперед.

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

• проводить внедрение одновременно во всех подразделениях компании, а не только в ИТ-службе;
• премировать подрядчиков в зависимости от удовлетворенности заказчиков;
• заручиться постоянной поддержкой президента компании.

Кстати, честолюбивых и амбициозных руководителей подразделений ИТ следует предупредить, что в их руках есть очень мощный инструмент для налаживания взаимодействия бизнеса с обслуживающими подразделениями, и если они решатся выступить в качестве проводника этого подхода в организации, то могут заслужить реальный повод для гордости и благодарность как со стороны бизнеса, так и от коллег из сервисных подразделений. Надежно работающими «железками» уже никого не удивишь, а вот сервисный подход — это то, в чем ИТ на голову опережает другие обслуживающие подразделения.

Дмитрий Воробьев (casne@ya.ru) — начальник отдела мониторинга качества процессов, Сбербанк России (Москва).