itSMF Russia :: Ассоциации организаций и специалистов в сфере управления информационными технологиями «ИТ сервис-менеджмент форум» баннер
НОВОСТИ УЧАСТИЕ В АССОЦИАЦИИ ОБ АССОЦИАЦИИ БИБЛИОТЕКА СОБЫТИЯ ДЛЯ УЧАСТНИКОВ ТРЕБУЮТСЯ СПЕЦИАЛИСТЫ БЛОГИ

баннер

 

баннер

 

поделиться

 

поделиться

Присоединиться к ITSM сообществу


Состав itSMF Russia

 


книжный магазин itSMF



Подпишитесь на новости ITSM-сообщества

* обязательные поля
Архив рассылок >>>



facebook linkedin баннер twitter



Реестр аккредитованных учебных центров, работающих в Российской Федерации и имеющих право проводить обучение по утвержденному списку курсов ITIL®


Manager’s Certificate in IT Service Management Список ITIL Expert'ов и сервис-менеджеров России и стран СНГ



Список российских профессионалов сервис-менеджмента, обладателей сертификатов priSM




Работа для Вас: актуальные вакансии


Как правильно составить SLA в ИТ?
CNews, Антон Фойгт, 09.07.2004
Untitled Document

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

SLA — осознанная необходимость

На определенном этапе успешного развития любого ИТ-проекта перед теми, кто принимает решения, возникает дилемма. Как поддерживать работоспособность бизнеса?

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

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

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

С одной стороны, резкое увеличение аутсорсинга и более чем оптимистичные прогнозы на будущее. Кроме того, определенные сложности в управлении создает возникновение все новых и новых проектов в ИТ-сфере.

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

Как подойти к описанию требуемого уровня качества, чем руководствоваться? Подобная практика получила емкое и исчерпывающее название — Service Level Agreement (SLA). Содержание термина SLA довольно четко раскрыто в нем самом.

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

7 мифов об SLA

1. Не нужно никакого SLA.

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

2. SLA просто описывает предоставляемые услуги.

Описание услуг — основной предмет SLA, что вполне естественно. Любая продуктивная совместная работа возможна при наличии общего языка. Именно при составлении SLA компании согласовывают общую терминологию.

Помимо указания на то, что и кому предоставляется, четко составленный SLA содержит множество важнейших подразделов: цель сотрудничества, его продолжительность, график предоставления услуг, условия оплаты, условия расторжения, гарантии, размеры компенсаций. SLA — основной и единственный инструмент для регулирования вопросов в сфере предоставления ИТ-услуг.

3. В SLA не должны быть указаны бизнес-цели клиента.

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

4. Оплата производится за предоставленные услуги.

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

К примеру, американская компания Intira, специализирующаяся на веб-хостинге, указывает в своих SLA, что она компенсирует каждые 15 минут отсутствия доступа к ресурсам клиентов одним днем бесплатного обслуживания и так — вплоть до месяца бесплатного обслуживания в год.

5. Все провайдеры предоставляют стандартные SLA.

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

Здесь просто не может идти речи о шаблонном SLA. Так, вице-президент аутсорсинговой компании Nuclio Corp. Майк Коффилд (Mike Coffield) отмечает, что каждый SLA его компании строится вокруг бизнес-требований конкретного клиента. На разработку соглашения подчас уходит до трех недель. «Мы не навязываем SLA пользователю, — отмечает Коффилд. — Мы вносим туда все, что ему необходимо».

6. Качество предоставляемых услуг невозможно измерить.

Пожалуй, — это главное заблуждение относительно SLA. В зависимости от типа услуги, потребители могут измерить качество ее предоставления по одному из параметров: доступность; среднее количество сбоев за определенный период, их динамика; время, затрачиваемое на их устранение.

Вице-президент е-commerce-портала Commerce One Inc. (компания предоставляет услуги хостинга и co-location для сотен известных американских компаний) Сэм Пратер (Sam Prather) отмечает: «На третий день после оформления SLA с компанией Siterock наши технические специалисты не получили ни единого уведомления о сбое. Через месяц услуги Siterock, обходящиеся нашей компании в $15 тыс., сэкономили нам $1,5 млн., избавили нас от головной боли и сохранили нам ценных специалистов». В настоящее время целым рядом экспертных организаций по всему миру разрабатываются унифицированные системы материальной оценки качества услуг в сфере ИТ.

7. Условия SLA распространяются только на того, кто его подписывает.

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

 Андрей Ботнев: Практика фиксирования договоренностей в письменном виде вполне естественна для любой сферы бизнеса

Андрей  Ботнев Практику составление SLA в ИТ-сфере для CNews.ru комментирует Андрей Ботнев, руководитель отдела разработки Columbus IT Partner Russia

CNews.ru: Чем, на ваш взгляд, обусловлен растущий интерес к вопросам составления SLA?

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

CNews.ru: Есть ли особенности при заключении договоров на аутсорсинг разных видов работ?

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

CNews.ru: На какие моменты вы бы посоветовали обращать внимание при заключении SLA?

Андрей Ботнев: При заключении контрактов на аутсорсинг основное внимание следует уделить параграфу, где прописаны количественные показатели измерения качества предоставляемых услуг, поскольку именно качество зачастую является камнем преткновения. Ведь ни для кого не секрет, что, как правило, основной причиной, по которой компании выбирают ИТ-аутсорсинг, является стремление снизить расходы. При этом поставщики часто пытаются сэкономить на качестве предоставляемых услуг.

Следующий момент, которому следует уделить внимание, — это безопасность.

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

CNews.ru: Спасибо.

Дмитрий Слиньков: В России до сих пор многие предприятия создают системы «под себя», своими силами

Дмитрий Слиньков Работу ИТ-отделов компаний и потребность составления SLA комментирует Дмитрий Слиньков, управляющий партнер «КОРУС Консалтинг».

Дмитрий Слиньков: SLA — достаточно новое для российского рынка понятие. Ведь в России до сих пор многие предприятия идут по пути, который кажется им оптимальным, — создание системы «под себя», своими силами. Да, в этом есть смысл, но только в том случае, если компания не планирует расти и развиваться. В противном случае она рискует через несколько лет получить раздутый штат собственных разработчиков и систему, которая безнадежно устарела с точки зрения новых реалий ее бизнеса.

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

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

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

CNews.ru: Спасибо.

Типовая модель SLA

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

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

Второй немаловажный компонент любого SLA — регламент доступности сервиса, включая время, потраченное на тестирование, текущую поддержку и модернизацию. Неотделимо от этого и число конечных пользователей услуги — к примеру, 2 миллиона GSM-абонентов, 15 тысяч посетителей сайта, тысяча FTP-пользователей или триста сотрудников офиса. В любом случае должно оговариваться обслуживаемое или задействованное в обслуживании оборудование.

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

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

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

Основные стратегические шаги при разработке SLA

Шаг 1: Требуйте только то, что нужно именно вам.

Например, основным видом деятельности компании является веб-хостинг. Поддержка его функционирования осуществляется сторонними организациями. В этом случае затраты на стопроцентную доступность составляют на порядок большие суммы, чем средства, направленные на поддержание 98% или даже 99% от теоретической работоспособности. Но более тщательный анализ позволяет сделать вывод, что даже в веб-хостинге отдельные приложения не требуют такого пристального внимания. Даг Плоткин (Doug Plotkin), директор по развитию массачусетской компании Meta Group Consulting, советует своим клиентам сопоставлять качество услуг, предлагаемое сервис-провайдерами в SLA, в соответствии с реальными потребностями бизнеса. Быть может, услуг с меньшей стоимостью поддержки их качества будет вполне достаточно? Тогда не потребуется ассигновать в два-три раза большие средства на их «hi-end»-аналоги.

Шаг 2: Уделяйте внимание защите важных компонентов.

Допустим, аутсорсинговая компания обеспечивает поддержку доступа к 50 вашим серверам, но SLA предусматривает компенсацию лишь в случае падения среднего уровня доступности ниже оговоренного показателя (практика SLA, именуемая «агрегация»). Тем временем на деле стопроцентная работоспособность обеспечена 49 серверам из 50: всем, за исключением самого важного. «Агрегационный мониторинг хорош лишь в том случае, когда отсутствуют критические узлы, сбои которых не позволяют функционировать всей системе целиком, — отмечает Даг Плоткин. — Зачастую при наличии критических компонентов провайдеру дешевле выплатить мизерную компенсацию, нежели уделять отдельное внимание подобным ключевым участкам». Массачусетский консультант советует заранее дифференцировать уровень качества обслуживания первостепенных частей и всех остальных.

Шаг 3: Четко определите термины.

В любом SLA должен иметься список определений для понятий, относящихся к качеству сервиса. Наоми Картен, CEO Karten Associates, а также автор книги «Разработка SLA», делится опытом: «Когда провайдер гарантирует вам доступ на уровне 98%, имеет смысл лишний раз уточнить — 98% чего?». По его словам, краеугольным камнем является схема осуществления мониторинга: как будет отслеживаться качество услуг, как будет осуществляться переход на его новые уровни, как и в какой форме провайдер будет отчитываться.

Шаг 4: Учитывайте наилучшие и наихудшие сценарии развития событий.

Здесь показателен пример с аутсорсингом телефонной службы поддержки пользователей. SLA предполагает, что на 90% звонков будет дан ответ в течение 30 секунд. Это означает, что сотрудники help-desk смело могут заставить оставшиеся 10% пользователей ожидать помощи неопределенное время. Решением в подобных ситуациях станет видоизменение соответствующего пункта SLA. Проблема будут решена, если записать: «Провайдер гарантирует заказчику, что на 90% звонков, поступивших в службу поддержки, будет дан ответ в течение 30 секунд; на оставшиеся 10% — ответ будет дан не позднее 60 секунд».

Шаг 5: Компенсация должна быть адекватной.

Бизнес, уничтоженный низким качеством технологического обслуживания либо плохим обеспечением безопасности, уже не нуждается в лишнем годе бесплатного сервиса в качестве компенсации. Здесь потребуется прямое возмещение материальных убытков, а не удешевление и без того некачественных услуг. Компенсация должна соответствовать причиненному ущербу. Например, в соответствии с SLA, заключенным между почтовым порталом MiracleMail.com и упоминавшейся выше компанией Intira, в случае, когда портал остается недоступным 15 минут, на 16 минуте начинается автоматическое пополнение банковского счета MiracleMail.com.

Шаг 6: Обязательная модернизация.

Условия долгосрочных SLA должны периодически пересматриваться. Так, по словам того же Дага Плоткина, 5 лет назад максимальная гарантия доступности сайтов, декларированная хостинг-провайдерами, составляла 95%. В настоящее время минимальный уровень гарантируемого провайдерами uptime равен 97%.
В заключение хотелось бы остановиться еще на одном немаловажном аспекте. Суть SLA состоит в том, что подобные соглашения остаются творческим продуктом двух независимых сторон. Однако на практике же редко встречаются ситуации, когда обоюдная работа ведется на каждом этапе создания SLA. Тем не менее, удачное, работоспособное SLA — это соглашение, над которым плодотворно потрудились и компания, предоставляющая услуги, и потребитель этих услуг. Когда такой процесс действительно имел место, SLA, по большому счету, может смело храниться в архиве, поскольку на этой стадии люди уже прекрасно знают, как им сотрудничать друг с другом, на чем базировать и как развивать партнерские отношения. А это и есть основная цель SLA.

Антон Фойгт

Полную версию статьи
Вы найдете на сайте издательства

Публикуется с разрешения издательства CNews.
Все права сохранены.



Помогите своим коллегам быть в курсе интересных новостей! Поделитесь!
Документ без названия


 

Приглашаем принять участие
в воркшопе ITSM Labs
баннер


баннер


баннер


Партнеры itSMF России



 Директор информационной службы
 

Information Management

Открытые системы



Московское отделение ISACA

ABPMP Russian Chapter

GlobalCIO

СоДИТ

SPb CIO Club — партнер itSMF России

Высшая школа бизнес-информатики Государственного университета – Высшей школы экономики (ВШБИ)

МИИТ

ГУУ

Московский государственный университет экономики, статистики и информатики (МЭСИ)

Факультет ВМК МГУ имени М.В. Ломоносова

Московский институт электроники и математики (МИЭМ)

Институт информационных бизнес систем



Блоги: