Все, что вы хотели знать о SLA. Соглашение об Уровне Услуг – SLA

Service Level Agreement – SLA – это соглашение между заказчиком и исполнителем, содержащий описание услуги, права и обязанности сторон и, самое главное, согласованный уровень качества предоставления данной услуги. Соглашение SLA четко прописывает временные рамки для устранения проблем, определяет штрафные санкции, накладываемые на нашу компанию в том случае, если качество услуг оказалось ниже прописанного в договоре уровня. Это позволит минимизировать ваши убытки. Таким образом, заказчик получает удобный способ контролировать услуги, быть уверенным в их полноте и качестве. Уникальность услуги в том, что SLA дает понятный ответ на вопрос «Хорошо или плохо работает служба поддержки?».

Структура

Типовая модель SLA должно включать следующие разделы:

• Определение предоставляемого сервиса, стороны, вовлеченные в соглашение, и сроки действия соглашения.
• Дни и часы, когда сервис будет предлагаться, включая тестирование, поддержку и модернизации.
• Число и размещение пользователей и/или оборудования, использующих данный сервис.
• Описание процедуры отчетов о проблемах, включая условия эскалации на следующий уровень. Должно быть включено время подготовки отчета.
• Описание процедуры запросов на изменение. Может включаться ожидаемое время выполнения этой процедуры.
• Спецификации целевых уровней качества сервиса, включая:
• Средняя доступность, выраженная как среднее число сбоев на период предоставления сервиса
• Минимальная доступность для каждого пользователя
• Среднее время отклика сервиса
• Максимальное время отклика для каждого пользователя
• Средняя пропускная способность
• Описания расчета приведенных выше метрик и частоты отчетов
• Описание платежей, связанных с сервисом. Возможно как установление единой цены за весь сервис, так и с разбивкой по уровням сервиса.
• Ответственности клиентов при использовании сервиса (подготовка, поддержка соответствующих конфигураций оборудования, программного обеспечения или изменения только в соответствии с процедурой изменения).
• Процедура разрешения рассогласований, связанных с предоставлением сервиса.
• Процесс улучшения SLA.

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

Зачем нужны SLA

Вспомним теорию. По ITIL, SLA (Service Level Agreement) – соглашение между поставщиком ИТ-услуг и заказчиком (по умолчанию – между ИТ-подразделением и основным бизнесом компании). В SLA описаны обязательства поставщика и условия предоставления услуг, а также обязанности и возможности заказчика по потреблению услуг. Заключая SLA с бизнес-структурой, ИТ-служба гарантирует предоставление услуги с уровнем качества не ниже согласованного .

• Описание сервисов / услуг, предоставляемых в рамках SLA (часть или весь каталог сервисов, предоставляемых ИТ-службой)
• Описание условий предоставления сервисов / услуг (вплоть до порядка обработки запросов на определенные услуги)

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

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

Внедрение Service Desk, безусловно, тесно связано как с определением каталога сервисов, так и с разработкой SLA. Поскольку:

• без каталога сервисов невозможно очертить зону ответственности ИТ-службы – а значит, грамотно подобрать ресурсы и организовать процессы работы
• без SLA невозможно задать ориентиры работы ИТ-службы (причем такие ориентиры, которые бы коррелировали с целями бизнеса). А без этого не будет понимания, движемся мы или стоим на месте, то есть насколько мы близки к соблюдению SLA. Куда приложить дополнительные усилия в первую очередь и т.п.

Ошибки

Отсутствие правил расставания

• Будет ли известно о расторжении заранее?
• Хватит ли суммы компенсации?

Невнимательность к санкциям

• Как будет компенсировано нарушение?
• Является ли ответственность соразмерной?

Нет механизма приостановления / возобновления работы

Неточность условий

• Какие запросы я буду получать?
• На какой результат я могу рассчитывать?

Как это сделать?

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

• Начните с одного / двух SLA для всей компании.
• Выделите группы пользователей, для которых вы будете предоставлять услуги разного качества, например:
• SLA для VIP-пользователей:
• SLA для всех остальных:
• Выделите критические сервисы, по которым вы считаете необходимым управлять качеством – то есть брать на себя обязательства и выполнять их. НО никогда не беритесь за разработку SLA по всем возможным направлениям сразу.
• Определите сроки для выделенных SLA. Как это сделать? Вообще, выбор целевых значений критических показателей качества работы (а это и есть разработка SLA!) – действие, изначально вытекающее из процессного подхода к управлению. Господа основоположники такого подхода (например, д-р Э.Деминг) завещают при выборе значений показателей отталкиваться от текущего состояния процесса. Нельзя ставить себе цель – выполнять работу за 20 минут – если текущее состояние процессов дает нам все 20 часов. Все, на что мы можем надеяться в ближайшем будущем – это сокращение на проценты, но не на порядок (так же, как сложно ожидать, что 9 женщин за 1 месяц родят целого ребенка). Другой вопрос, если из 20 часов 19 проходит в ожидании своей очереди. Тогда мы можем кардинально повлиять на изменение процесса.

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

• Начните измерять фактическое соблюдение параметров качества.
• Когда станет очевидно, что заявленные в SLA сроки работают не всегда и в 50% случаев нарушаются или бизнес ставит новые задачи, выделяя новые критические сервисы – начинайте детализировать услуги и корректировать условияSLA.

Иногда разговаривая с клиентами, мы слышим: «нет, мы еще не приступили к внедрению Service Desk – сначала разрабатываем SLA. Уже пару месяцев как…». Такой подход имеет безусловное право на существование, но в том случае, если ИТ-подразделение в состоянии установить сколько-нибудь правдоподобные параметры качества для услуг, включенных в SLA. Однако часто мы не можем установить время, за которое готовы отвечать. Для примера: при подготовке нового рабочего места иногда мы тратим неделю, потому что нам нужно что-то покупать, а иногда один день - мы передаем оборудование со склада и пр. Или ключевыми для нас являются новые сервисы, по которым мы пока не можем предположить, сколько времени займет их обслуживание. В этих случаях целесообразно сначала запустить в работу Service Desk без SLA, чтобы получить статистические данные по срокам обслуживания тех или иных сервисов из каталога.

Резюме: при разработке SLA необходимо учитывать несколько ключевых моментов

• Параметры качества, определяющие, как должны функционировать сервисы – то есть как измерить, достигнута ли ИТ-службой поставленная цель – должны быть измеримы.
• Установленные параметры должны быть достижимы в текущей жизни ИТ-службы. Такая организация работы само по себе мотивирует персонал. А вот если задача понятна, но недостижима – от нее нет никакого толку.
• Не всем пользователям должны быть доступны все сервисы и услуги (например, запросить услугу по созданию нового почтового ящика могут только руководители бизнес-единиц; а сообщить об инциденте могут все пользователи). Соответственно, необходимо планировать разработку нескольких SLA с разными группами пользователей
• Разные сотрудники компании требуют разных условий оказания одних и тех же услуг. Например, допустимо устранять сбой в работе ПК на рабочем месте секретаря за 4 часа. А рабочий ПК директора не может простаивать более получаса. И правила, от чего зависит характер обработки запроса, мы тоже должны учесть в SLA. Стрелочки.PNG
• Для любого обращения в ИТ-службу важным является набор входящей информации. Таким образом, в SLA должны включаться параметры входящей информации, являющиеся обязательным условием, обеспечивающим выполнение ИТ-службой своих обязательств.
• Предусмотреть способы измерения фактических параметров качества.

Постепенно двигаясь вперед (всегда - по необходимости бизнеса, не по собственной фантазии), вы достигнете того баланса, когда.

Делая ставку на аутсорсинг, необходимо понимать, что результативность партнерства напрямую зависит от схемы взаимодействия заказчика и исполнителя, и секрет успеха во многом определяется грамотным соглашением Service Level Agreement, SLA (в дословном переводе означает «Соглашение об Уровне предоставления Сервиса»).

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

Что должно быть отражено в SLA?

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

• Перечень услуг, которые будет оказывать подрядчик
• Формат и форма предоставления сервиса
• Критерии оценки качества выполнения работ
• График выполнения работ
• Разделение ответственности сторон
• Вопросы обеспечения соответствия требованиям закона
• Механизмы мониторинга деятельности и предоставления отчетности
• Порядок и принципы оплаты
• Процедуры разрешения споров
• Категории конфиденциальных данных, не подлежащих разглашению
• Условия прекращения действия договора.

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

Борьба за эффективность

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

В общем случае существует 4 вида характеристик работ – это объем, качество, оперативность и эффективность. Численное определение данных параметров позволяет создать метрики для оценки уровня обслуживания. Чтобы правильно подобрать критерии оценки работы, мы предлагаем придерживаться пяти основных принципов:

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

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

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

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

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

Построение партнерства

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

Соглашения об уровне обслуживания (Service Level Agreement, SLA), - не что иное, как контракт, заключаемый двумя сторонами. В основном такие соглашения заключаются в области ИТ-услуг и описывают уровень сервиса, предоставляемого клиенту за определенный гонорар. SLA также оговаривает средства правовой защиты клиента, например, уменьшение гонорара в случае перебоев в оказании услуги.

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

Что такое SLA?

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

Классическим примером SLA может служить договор с поставщиком сетевых или телекоммуникационных услуг, предусматривающий штрафные санкции по отношению к поставщику в случае неоказания услуги в полном объеме. Обычно штрафные санкции оговариваются по ступенчатому принципу. Например, если сеть недоступна в течение часа, поставщик лишается 10% месячной оплаты; если сети нет два часа - 20%, и т.д.

В чем важность SLA?

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

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

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

Из каких элементов обычно состоит SLA?

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

Нужен ли пункт о возмещении ущерба?

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

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

Передаются ли обязательства по соглашению третьей стороне?

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

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

Как удостовериться, что поставщик исполняет SLA?

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

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

Что такое мониторинг и проверка исполнения SLA?

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

Каковы основные параметры исполнения SLA?

Большая часть показателей в соглашении об уровне обслуживания измеряют качество работы поставщика услуг. Ян Хэйес из компании Clarity Consulting, поясняет, что определение качества может включать в себя как отдельные показатели приемлемости уровня предоставляемого сервиса, так и какой-то один из показателей, выбранный как критерий качества.

Вот примеры параметров качества.

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

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

Доступность сервиса. Определяет количество времени или временной промежуток, в котором услуги, предоставляемые подрядчиком, остаются доступными. Этот параметр применяется к широкому спектру услуг, от доступности указанного онлайн-приложения до соблюдения сроков предоставления отчетов. Параметр может принимать значения «да» или «нет». Обычно оговаривается допустимый уровень отказов (к примеру, онлайн-приложение должно быть доступно в течение 99% промежутка времени от 8:00 до 18:00 по восточному времени).

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

Какие параметры исполнения в SLA выбрать?

Вот что советует Хэйес.

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

Во-первых, следует сконцентрироваться на том, какого именно поведения вы хотите добиться. Затем имеет смысл проверить эффективность рассматриваемых параметров, мысленно поставив себя на место противоположной стороны. Каким образом вы бы оптимизировали производительность? Приведут ли эти изменения к тому результату, к которому стремитесь вы?

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

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

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

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

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

Когда речь идет о хостинговых сетевых услугах, большинству компаний требуется как минимум 99% времени работы без простоя. Многие поставщики услуг хостинга гарантируют 99,9% времени бесперебойной работы или даже больше. Важно понимать, что конкретно это означает: к примеру, 99,9% времени работы без простоя - это 43,2 минуты простоя в месяц. Для многих предприятий такой уровень перебоев неприемлем. Стандартная практика - когда поставщик услуг предлагает уровень бесперебойной работы, близкий к ста процентам, если это имеет серьезное значение для целей заказчика. Однако за такие гарантии нужно платить. Многие провайдеры предлагают спектр гарантий бесперебойной работы разного уровня, различающихся по цене.

Следует ли время от времени пересматривать договор?

Если коротко: да. Обязательства по уровню услуг в SLA определяются, исходя из потребностей клиента на данный момент времени, а они могут изменяться.

Соответственно, SLA должно рассматриваться как динамически изменяемый документ, нуждающийся в периодическом пересмотре и внесении изменений в следующих случаях:

Изменение внешних обстоятельств;

Изменение ожиданий и/или потребностей клиента;

Изменение рабочей нагрузки;

Появление лучших средств, процедур и параметров измерения производительности.

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

Lauren Gibbons Paul. ABC: An Introduction to Service-Level Agreements (SLAs). CIO Magazine. August 08, 2007

KPI не равно SLA

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

Разумеется, имеет смысл обратиться к официальному словарю ITIL (см. врезку). Сразу же бросается в глаза ключевое различие в сути каждого из этих терминов. Если в SLA обязательно участвуют две стороны (заказчик и поставщик услуг), и это список измеряемых характеристик оказываемой услуги и сроков исправления нарушений ее предоставления, то KPI – это некий показатель, которым измеряют фактически предоставляемые услуги.

Краткий словарь терминов SLA (Service Level Agreement) – Соглашение между поставщиком ИТ-услуг и заказчиком. Соглашение об уровне услуг описывает ИТ-услугу, документирует целевые показатели уровня услуги, указывает зоны ответственности сторон – поставщика ИТ-услуг и заказчика. KPI (Key Performance Indicator) – Метрика, которая используется для управления ИТ-услугой, процессом, планом, проектом или другой деятельностью. Ключевые показатели эффективности используются для измерения реализации ключевых факторов успеха. SLR (Service Level Requirement) – Требование к уровню услуг. Требование заказчика к ИТ-услуге. Требования к уровню услуг основаны на бизнес-целях и используются для переговоров и согласования целевых показателей уровня услуг.

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

В самом начале

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

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

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

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

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

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

Если свести этот документ к некому формуляру, данные из которого можно смело переносить в SLA и использовать для создания KPI, то получится вот такой список (см. таблицу 1).

Таблица 1. Формуляр, данные из которого можно переносить в SLA и использовать для создания KPI

Описание услуги	Указывается общепонятное название услуги, которое должно быть понятно при использовании как внутри компании, так и за ее пределами. В этом же пункте описываются «Критерии успеха», т.е. в каких условиях данная услуга считается оказанной качественно. Например, если услуга в рабочие часы доступна 99% времени, значит, она оказывается успешно. Не лишним будет указать емкость данной услуги, описав, если возможно, такие параметры, как: возможность выполнять запросы «X» количества пользователей; количество транзакций в минуту/секунду; границы пиковых нагрузок
Распределение ролей и ответственных за услугу	В этом разделе отображаются конкретные имена владельцев и исполнителей, ответственных за услугу как со стороны бизнеса, так и от ИТ
Требования по поддержке услуги	Необходимо указать, каким образом бизнес-заказчик представляет временные рамки по доступности системы, ее регламентированному обслуживанию и исправлению возникших сбоев
Задействованные подразделения	Описываются зависимые от услуги подразделения компании. Если с почтой или 1С, как правило, все понятно, то с какой-нибудь новой CRM-системой или мобильным приложением может быть не все очевидно
Задействованные бизнес-транзакции	В этой части необходимо описать, какие важные для бизнеса действия осуществляются, используя именно этот сервис, что будет невозможно выполнить, если сервис перестанет функционировать. Данный параметр поможет более корректно выставлять приоритеты во время поступающих инцидентов
Инциденты и сбои	Первое, с чего необходимо начать заполнение данного раздела, – это описать способы корректных коммуникаций для того, чтобы обратиться в ИТ-подразделение, и, наоборот, ИТ-службе корректно информировать сотрудников о событиях, происходящих с данной услугой. Тут также описываются целевые показатели времени решения выявленных инцидентов и сбоев в зависимости от их приоритетов. Нелишним будет ввести таблицу передачи разрешения инцидента на более высокий уровень, распределив моменты эскалирования в зависимости от приоритета и прошедшего времени
Плановый простой услуги	Плановое обслуживание элементов, необходимых для качественного оказания услуги, требует планирования времени простоя (Downtime), которое не будет считаться как сбой или прерывание оказания услуги. В этом разделе необходимо описать возможную частоту, временные рамки и способы информирования, если необходимо, о фактах прерывания на плановое обслуживание, предоставления услуги
Запросы на обслуживание и обучение	Необходимо указать, каким образом формируются «запросы на обслуживание», в какие сроки и в каких объемах возможно исполнение обращения по данной услуге. Как правило, введя в действие услугу, редко задумываются о том, что необходимо произвести обучение по корректному использованию услуги, а это может оказаться важным элементом требований бизнеса

OLA (Operational Level Agreement, Соглашение операционного уровня)

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

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

Словарь ITIL дает определение для OLA как «Соглашение между поставщиком ИТ-услуг и другой частью той же организации». Слова «той же организации» являются ключевыми.

Если, например, речь идет о соглашении по срокам исправления неисправности доступа в сеть интернет или качества самого соединения со стороны провайдера, то это с точки зрения ITIL будет «Внешний договор» (UC, Underpinning Contract).

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

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

Ради чего все эти сложности

Собрав требования бизнеса (SLR) и договорившись с нужными для оказания услуг подразделениями (OLA), можно приступать к написанию итогового документа – «Соглашения об уровне услуг». Все зависимости документов изображены на рис. 1.

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

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

Само по себе соглашение (SLA) должно содержать четкие ответы на следующие четыре вопроса:

• Какие сервисы?
• Кому конкретно предоставляются?
• Какого именно качества он должен быть?
• В какие сроки должны быть устранены отклонения от описанных параметров в п. 3?

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

По определению в официальной книге ITIL:Service Design в зависимости от разреза услуги SLA делятся на три группы :

• Service-based (От услуги) – все заказчики получают одинаковые условия на один и тот же сервис.
• Customer-based (От потребителя) – условия различаются в зависимости от заказчика (и, разумеется, за разную цену).
• Multi-level (Многоуровневый) – условия описываются для компании, клиентов и служб, при этом каждый раз они различаются.

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

Разработка полноценного «Соглашения об уровне услуг» – показатель зрелости бизнес-процессов в ИТ-подразделении компании и определенный шаг вверх с точки зрения измерения качества взаимодействия между ИТ и другими подразделениями.

Как и что писать

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

Главным посылом при разработке документа должно выступать для обеих сторон желание устанавливать реальные нормы качества для SLA, с учетом возможностей подразделения и целевых показателей, описанных в SLR. Ну, конечно, нельзя подходить к процессу с точки зрения «генерации» договора с красивыми, но не отражающими реалии словами.

Собирать информацию для данного документа рекомендуется:

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

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

Важно не забыть и дать описания таких понятий, как «Аварийная ситуация», «Инцидент», «Стандартное время регламентных работ (обслуживания)», «Доступность» и «Система регистрации заявок».

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

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

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

Каждый уровень «деградации» сервиса (см. таблицу 2) описывается в разрезе таких параметров, как «Время реакции на запрос (передача запроса на исполнение ответственному специалисту)», «Время выполнения (информирование заказчика о факте завершения запроса)». Последний столбец такой таблицы – стоимость неустойки за час или каждый просроченный случай.

Таблица 2. Уровни «деградации» сервиса

Уровень сервиса	Время реакции на запрос (передача запроса на исполнение ответственному специалисту)	Время выполнения (информирование заказчика о факте завершения запроса)
Аварийный	15 минут	1 час
Средний	20 минут	8 часов
Низкий	1 час	24 часа

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

SLA – не обязательно документ с подписями и печатями

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

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

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

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

Как мы выяснили, просто так разбрасываться «умными» терминами не стоит, лучше понимать, что же скрывается за красивыми аббревиатурами.

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

1. Словарь терминов и определений ITIL 2011 на русском языке – http://www.itsmforum.ru/ZAM-test .
2. «ITIL® Service Design 2011edition», London: TSO, ISBN 9780113313051, p.111.

09.07.2004, ПТ, 14:07, Мск

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

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

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

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

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

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

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

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

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

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

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

Как подойти к описанию требуемого уровня качества, чем руководствоваться? Подобная практика получила емкое и исчерпывающее название — 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

Из всего многообразия возможных ИТ-сервисов, для предоставления или получения которых необходимо 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.