Rambler's Top100
Статьи
Лилия ПАВЛОВА  09 ноября 2010

Э. Гатиятуллин (Ай-Теко): "SLA сегодня носят односторонний характер: требования касаются прежде всего аутсорсера"

Соглашение об уровне предоставляемых услуг SLA – своего рода книга жизни аутсорсера и заказчика, по которой они сверяют свои взаимоотношения. Задача для обоих – предусмотреть в ней все возможные повороты событий. Читайте полную версию Дискуссионного клуба темы номера "ИКС" №10'2010, "ИТ-аутсорсинг. Профессиональное сопровождение". Часть 6. 

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

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

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

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

Олег Клинов, руководитель департамента аутсорсинга и сервисного обслуживания компании «Verysell Проекты»: Проблемы, как правило, начинаются, когда в SLA нечетко прописаны условия сотрудничества. В этом случае от заказчика начинают поступать заявки, которые в договор не укладываются, что может привести к конфликтам.

Андрей Гешель, директор Сервисного центра компании “Инфосистемы Джет”: У профессиональных аутсорсеров такой проблемы не существует. Основной подход - это честность по отношению к заказчику и своевременная отчетность. При составлении SLA сторонам важно четко сформулировать и зафиксировать детали и параметры SLA, а  исполнителю - адекватно оценить свои силы.  Обе стороны должны одинаково понимать каждый параметр SLA, без двойного трактования.

Валерий Корниенко, руководитель направления развития сервисных услуг IBM: Проблема отслеживания уровня предоставляемых услуг обычно заключается в слабой детализации того, какие услуги и как предоставляются и что является критерием успешного предоставления услуг. Если это отражено в контракте – например, у нас это занимает 4-5 страниц текста, в котором мы описываем, как работает каждая компонента, где вы можете рассчитывать на наш ответ в течение 10 минут, где нет, - заказчик, подписывая контракт, уже знает, что он может требовать, чего нет, и проблем с отслеживанием уровня услуг не возникает.

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


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

Необходимо проанализировать следующие риски:

*Потеря контроля со стороны заказчика (риск зависимости от поставщика),

*Потеря качества при переходе на аутсорсинг,

*Риски, связанные с утечкой информации,

*Риски при прекращении аутсорсингового договора.

В договоре обязательно должен присутствовать некий пункт, что в случае разрыва/прекращения договора исполнитель (аутсорсер)передает всю базу знаний  по проекту заказчику. И тогда риск потерять контроль сводится к нулю. Плюс сам заказчик должен выделить некоего сотрудника, который будет регулярно контролировать качество выполнения контракта и принимать участие в составлении базы знаний.

Замечу, что риск можно эффективно минимизировать только в том случае, когда между компанией-заказчиком и подрядчиком налажено открытое сотрудничество и достигнуто четкое взаимопонимание, закрепленное юридическим соглашением.

Владимир Фролов, руководитель направления ИТ-аутсорсинга компании «Микротест»: При составлении SLA обратите внимание, чтобы параметры качества услуг, механизм их измерения были понятными. Также важно предусмотреть возможность получать отчеты по согласованным метрикам в любое удобное для заказчика время. В тексте соглашения важно четко прописать:

*Состав выполняемых работ по каждой услуге (причем как работ по устранению аварий, так и планово-профилактических с целью недопущения сбоев).

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

*Возможность изменения стоимости оказываемых ИТ-услуг при изменении потребностей заказчика и алгоритм перерасчета стоимости.

*Модель взаимоотношений: кто за что отвечает, к кому и когда обращается и т.д.

*План перехода на модель ИТ-аутсорсинга и план возвращения на исходные позиции при необходимости прекратить договор. Последнее особенно актуально в случае перевода ИТ-персонала Заказчика в штат аутсорсера.

Барт Стаеленс, директор по стратегическому маркетингу Orange Business Services в России и СНГ: При составлении SLA необходимо учитывать не столько те параметры качества, которые предлагает аутсорсер, сколько требования самого заказчика, сформированные на основе его опыта. При этом операторы связи с собственной сетевой инфраструктурой могут предложить больше гарантий своим заказчикам: так, в Orange SLA предусмотрены как на сетевом уровне, так и на уровне приложений и конечного оборудования. Такие комплексные SLA необходимы, чтобы заказчик мог получить современные телекоммуникационные сервисы, работающие с заданными параметрами и производительностью.

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

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

Эдуард Гатиятуллин, руководитель отдела конструирования услуг Сервисного центра компании «Ай-Теко»: Безусловно, основа договоров на ИТ-аутсорсинг, что отличает их от договоров на техническую поддержку, — это соглашение об уровне услуг, в котором очень большой раздел посвящен требованиям к исполнителю. Обычно исполнитель заинтересован в наиболее подробном заполнении этого раздела, чтобы заказчик понимал, какие работы и как будут выполняться, какой документооборот будет этому сопутствовать и т. д. Управление уровнем обслуживания призвано гарантировать поддержку и постоянное совершенствование необходимых заказчику ИТ-услуг. А вот при выработке требований к заказчику возникает немало проблем, так как заказчик не всегда хочет брать на себя ответственность, которая бы выходила за рамки его прямых обязанностей. Поэтому на сегодняшний день соглашения об уровне услуг носят односторонний характер, требования касаются прежде всего исполнителя. Такие важные уровни ответственности, как допуск на объекты в определенное время, предоставление со стороны заказчика ответственных лиц определенной квалификации, выполнение требований документооборота очень часто не предусматриваются в рамках таких соглашений.

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

Игорь Пчелинцев,  руководитель  направления по проектированию сервисных решений департамента Siemens IT Solutions and Services компании "Сименс": Первое: чётко описать услугу и её рамки. Второе: определить контролируемые KPI этой услуги.

Сергей Таран, генеральный директор компании «ОНЛАНТА»: Традиционно провайдер услуг и заказчик заключают договор и соглашение об уровне услуг (SLA). В первом описаны общие обязательства компаний, а второе описывает параметры оказания услуг и ключевые показатели эффективности (KPI). Основная цель введения этих параметров – сделать работу провайдера измеряемой, а её оценку – объективной. Подрядчик несёт финансовую ответственность за соблюдение параметров SLA. Если показатели услуг ниже значения, зафиксированного в SLA, то подрядчик выставляет заказчику счет на сумму ниже договорной. У западных компаний существует практика, когда исполнитель, предоставивший услугу с более высокими значениями KPI, чем в договоре, получает более высокую плату.Однако оценивать работу исполнителя только на соответствие параметрам SLA уже недостаточно. Заказчик заинтересован в более детальной оценке, отражающей связь KPI с эффективностью своего бизнеса. Для сбора такой информации необходимо изменить подход к анализу результатов, полученных от предоставляемой услуги.

Оценивая изменение значений KPI во времени, можно смоделировать ситуацию, которая с определенной долей вероятности произойдет в будущем. Например, если среднее время решения инцидентов пользователей сокращалось, то тенденция положительная: сокращается время простоя при работе c информационной системой. А это напрямую влияет на прибыль – снижаются потери рабочего времени сотрудников. И наоборот, увеличение времени решения инцидентов — повод для дополнительного расследования причин.

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

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

Таким образом, измерение KPI дает много дополнительных возможностей оценки качества работы исполнителя. Уровень исполнителя сегодня определяется не только наличием SLA, но и спектром инструментов анализа KPI, а также опытом использования этих инструментов.Так, измерение KPI, их анализ и предоставление регулярных отчетов заказчикам позволяют «ОНЛАНТА» готовить рекомендации по улучшению услуг. Такие рекомендации периодически обсуждаются с заказчиками и на их основе разрабатывается план мероприятий по улучшению услуги.

Обязательное предоставление отчетов по оказанным услугам предусматривается условиями заключаемых договоров. Отчеты формируются по согласованным KPI, утвержденным в SLA. Кроме того, заказчик может получить ряд дополнительных отчетов, отражающих динамику развития услуги, тенденции и иные управленческие данные. Для повышения оперативности и удобства отчеты могут предоставляться заказчикам не только в виде приложений к актам сдачи-приемки работ, но и в личном кабинете клиента на web-сайте.Подробно об SLA и KPI в услуге «Поддержка пользователей» читайте на http://onlanta.ru/blogs/index.php 
Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!