Заказчики и IT-компании на аутсорсе часто заключают SLA соглашение вместо обычного договора. Из этой статьи вы узнаете, в чем его особенности и отличия, а также кому стоит выбирать этот тип договора.
SLA – это соглашение об уровне сервиса. Оно регулирует взаимоотношения между клиентом и исполнителем, который предоставляет IT-услуги. В SLA подробно описаны такие моменты:
Основное отличие от типового договора заключается в том, что SLA более детально описывает каждую услугу, а также предоставляет параметры для оценки качества обслуживания.
Например, если в обычном договоре указано, что исполнитель обязуется устранять неполадки после заявки клиента, то в SLA будет четко указано, что поставщик обязуется приступить к устранению проблемы в течение, например, 45 минут в будние дни с 8:00 до 19:00 и завершить работу за 4 часа.
В этом договоре детально описывают все параметры, которые позволяют оценить качество предоставляемой услуги и обслуживания в целом. Вот основные из них:
В договоре могут быть и более сложные типы метрик, например, соотношение между количеством проблем и вносимых изменений. Этот параметр показывает, какое количество неполадок возникает из-за исправления предыдущих ошибок.
Еще одна достаточно популярная метрика – это контроль возраста запроса. Например, в SLA может быть указано, что в работе не должны оставаться задачи старше 14 дней. Использование этой метрики помогает контролировать оперативность решения проблем заказчика.
Несмотря на все преимущества соглашения о предоставлении услуг, этот тип договора подходит не всем и не во всех ситуациях. SLA можно подписывать в том случае, если услуги нормируемые (их можно описать и измерить при помощи метрик) и регулярные.
Если заказчик ставит перед исполнителем много уникальных и сложных задач, составлять SLA не имеет смысла. Ведь исполнитель не может точно определить, сколько именно времени он потратит на задачу, с которой еще не работал.
В SLA также не вписываются очень масштабные и нетипичные задачи, например, когда заказчику нужно изменить функциональность одной из систем или интегрировать новое ПО. Второй тип задач – устранение глубинных проблем, из-за которых возникают повторяющиеся инциденты.
Доработка и устранение глубинных проблем не вписываются в SLA потому, что исполнитель не сможет даже примерно предвидеть, сколько времени займет решение задачи.
Договор SLA нужен в тех случаях, когда вся система или определенные ее функции критически важны для работы бизнеса. Когда такая технология выходит из строя, бизнес терпит убытки и не может нормально работать. Если же отключение системы на длительное время не влияет на работу бизнеса, можно обойтись без SLA.
Важно помнить, что SLA – это не лекарство от всех бед, а всего лишь разновидность договора. Если взаимоотношения между исполнителем и заказчиком уже давно налажены и рабочие процессы исправно функционируют, желательно хорошенько все взвесить перед тем, как переходить к новой форме сотрудничества.
SLA часто представляют как договор, в котором прописаны требования и ожидания заказчика, а исполнитель со своей стороны просто соглашается им следовать. На самом деле это не так. SLA принесет пользу только в том случае, если его условия адекватные и составленные с умом.
Конечно, бизнес теряет деньги, когда важная система не работает. Но технические аспекты из-за этого никуда не деваются. Для устранения проблемы нужно время. Чтобы условия договора устраивали заказчика и при этом не требовали от исполнителя нечеловеческих усилий, клиент и провайдер должны составлять SLA вместе.
Обычно это происходит таким образом:
Смысл диалога не в том, чтобы заставить вторую сторону пойти на уступки и склонить ее к своим условиям. Главная цель обсуждения – найти решение, которое устроит и бизнес, и провайдера услуг.
Мы часто сотрудничаем с клиентами именно по этому договору и по своему опыту знаем, что практически у каждой проблемы может быть несколько способов решения. Вернемся к нашему примеру. Клиент хочет, чтобы система восстанавливалась за 2 часа, а исполнитель объясняет, что на это нужно в два раза больше времени. Из этой ситуации есть несколько выходов. Можно уменьшить объем базы данных, разделив ее на несколько частей или удалив ненужную информацию. Или же можно улучшить инфраструктуру, купив новые сервера и хранилища.
Заключая соглашение SLA, важно помнить, что соблюдение этого договора не гарантирует 100% удовлетворенность клиента. Почему так получается? Это отлично можно продемонстрировать на примере двух ситуаций.
В первом случае у клиента регулярно возникает одна и та же проблема. Провайдер IT-услуг оперативно устраняет неисправность и вкладывается в оговоренные сроки. Но ощущение удовлетворенности зависит от эмоционального фона. Если пользователь регулярно сталкивается с тем, что система не работает или работает некорректно, это вызывает раздражение. Качественно выполненная работа IT-специалистов не может перекрыть эти эмоции. Получается, что договор соблюден, а удовлетворенность все равно низкая.
Во втором случае исходные данные те же: часто возникает однотипная проблема. Но провайдер решает подойти к ситуации с другой стороны. Он выявляет первопричину постоянно возникающих неполадок и устраняет ее. Это занимает больше времени и в установленные SLA сроки исполнитель не укладывается. Тем не менее, проблемы больше не возникают и заказчик удовлетворен уровнем обслуживания.
Работая с клиентами, мы также стараемся обнаружить и устранить первопричину, чтобы проблема больше не возникала. При этом на этапе составления SLA мы стараемся предусмотреть все нюансы, чтобы укладываться в срок даже при реализации нестандартных задач.
Грамотно составленный договор дает много преимуществ как заказчику, так и исполнителю. Выгода клиента заключается в следующем:
Исполнитель также получает ряд преимуществ:
Важно помнить, что эффективность SLA зависит от того, насколько корректно он составлен. Чтобы избежать недопонимания и сложностей в будущем, важно еще на этапе составления договора детально обсуждать все нюансы. А для этого заказчику и исполнителю следует прислушиваться друг к другу и стараться найти общий язык.
Input your search keywords and press Enter.