Соглашения об уровне обслуживания (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
Обговорили Рабочее время, которое считается общепринятым:
2. Рабочее время
Стороны договорились о том, что рабочим временем является промежуток с 9:00 до 18:00 во все дни, кроме субботы, воскресенья и общегосударственных праздничных дней.
Теперь описываем метрики, которые будут использоваться в качестве основополагающих критериев в оценке качества предоставляемых услуг:
3. Метрики сервиса
Стороны договорились об использовании следующих метрик уровня сервиса:
3.1 Время реакции на обращение пользователя
– время, прошедшее с момента поступления и регистрации запроса на обслуживание (сообщение пользователя о проблеме) до момента фактического начала работ по факту обращения. Временем поступления обращения считается момент поступления электронного письма на адрес [email protected], регистрации сообщения через онлайн службу регистрации инцидентов, предоставленную Исполнителем, или телефонного звонка в службу технической поддержки с сообщением о проблеме.
3.2 Время решения проблемы
– время, прошедшее с момента фактического начала работ над проблемой до закрытия заявки. Временем начала работы над проблемой считается момент отправки Заказчику уведомления о начале работ. Временем решения проблемы считается момент отправки Заказчиком сообщения, подтверждающего закрытие заявки. Подтверждение или опровержение выполнения работ должно быть отправлено Заказчиком в течение 1 часа с момента поступления от Исполнителя уведомления о выполнении заявки на обслуживание. В противном случае заявка считается закрытой автоматически, и временем закрытия заявки является момент отправки уведомления о завершении работ. Уведомления о начале и завершении работ направляются Исполнителем представителю Заказчика, от чьего имени поступила заявка на обслуживание, по электронной почте телефону или через Службу Онлайн Заявок.
3.3 Время жизни инцидента
– суммарное время, прошедшее с момента поступления и регистрации обращения, до момента закрытия заявки на обслуживание.
Теперь те самые уровни сервиса, о которых мы заключаем соглашение:
4. Уровни сервиса
Сервис, предоставляемый Исполнителем, делится на уровни в соответствии с установленными значениями метрик:
Табл. 1.
Уровень критичности |
Описание инцидента |
| Аварийный |
|
| Средний |
|
| Низкий |
|
В соответствии с классификацией, каждому виду инцидентов назначается время реакции, и время устранения в рабочих часах. Ответственность Исполнителя определена в рублях, за каждый факт несоблюдения нормативов метрик:
Табл.2.
Наименование уровня сервиса |
Наличие удаленного доступа | Отсутствие удаленного доступа | Неустойка за неисполнение нормативов. (руб./час) | ||
| Время реакции | Время устранения | Время реакции | Время устранения | ||
| Аварийный | 20 минут | 1 - 3 час | 30 минут | 1,5 - 5 часа | 300 |
| Средний | 30 минут | 2 – 4 часа | 40 минут | 3,5 - 5 часа | 200 |
| Низкий | 1 час | По согласованию | 1 час | По согласованию | 150 |
5. Перечень мероприятий
По технической поддержке ИТ-инфраструктуры Заказчика
Исполнитель выполняет по поручению Заказчика следующие мероприятия, связанные с обслуживанием и поддержкой существующей ИТ-инфраструктуры:
Оказание консультаций пользователям ИС Заказчика, решение проблем пользователей, связанных с функционированием ИС Заказчика и ее составных частей;
Поддержание работоспособности и доступности основных сетевых служб заказчика на уровне, указанном в данном соглашении.
Проведение мониторинга элементов и подсистем ИС заказчика, а также профилактических работ, направленных на поддержание работоспособности ИС заказчика в целом;
Осуществление резервного копирования (в случае предоставления Заказчиком соответствующих программных и аппаратных средств, в распоряжение Исполнителя);
Информирование Заказчика о необходимости модернизации ИС и ее элементов, а также замены вышедших из строя элементов;
Консультации по приобретению вычислительной и копировально-множительной техники для нужд Заказчика;
Поставка компьютерной, копировально-множительной и офисной техники по ценам Исполнителя в соответствии с требованиями Заказчика;
Установка обновлений системы 1С Предприятие версии ______.(в случае предоставления Заказчиком лицензионных идентификаторов доступа к серверам обновления указанных Программных продуктов).
Сопровождение продуктов 1С на уровне администрирования ресурсов системы и Базы данных.
Установка обновлений информационно-правовой системы ___________ (в случае предоставления Заказчиком лицензионных идентификаторов доступа к серверам обновления указанных Программных продуктов).
К работам по осуществлению технической поддержки не относятся работы, связанные с частичным или полным выполнением должностных обязанностей сотрудников Заказчика. В частности, сотрудникам Исполнителя запрещено выполнять по поручению сотрудников Заказчика такие работы как:
Создание, редактирование, форматирование и прочая работа с документами с использованиями офисных приложений типа MS Word, MS Excel, MS PowerPoint и подобных им;
Создание и редактирование графических, аудио и видеофайлов, флэш-презентаций и прочих медиа-файлов;
Редактирование наполнения и верстка web-сайтов, вчт. с использованием CMS;
Написание и отправка сообщений по электронной почте, ведение переписки от имени сотрудников Заказчика;
Поиск информации в сети Интернет;
Размещение файлов на FTP-серверах и скачивание файлов;
Отправка факсов;
Распечатывание и сканирование документов, изготовление ксерокопий документов;
Ремонт оборудования, не относящегося к ИС заказчика;
Выполнение погрузочно-разгрузочных работ;
Выполнение курьерских поручений, кроме передачи Исполнителю документов, связанных с исполнением настоящего договора.
Ну и последним штрихом пункт с ценами, но тут уже рассчитывайте на персональную жадность своих коллег.
Нам подобного соглашения было вполне достаточно для того, чтобы оградить себя от непонимания со стороны заказчика и его сотрудников. Данные приведенные здесь это абстрактный набор услуги метрик и не является единственно правильным, он просто отображает направления развития SLA как такового в небольших аутсорсинговых компаниях.
КАК ОПРЕДЕЛИТЬ, ПРОКОНТРОЛИРОВАТЬ И ПОВЫСИТЬ УРОВЕНЬ СЕРВИСА?
Одним из важнейших критериев выбора поставщика или обслуживающей организации наряду с ценой является качество предоставления услуг. Любой бизнес заинтересован в повышении уровня сервиса, но не каждый знает, как его вообще установить, проконтролировать и тем более улучшить. В этом помогает SLA. Разберемся, что это и как применяется.
Определимся с понятиями
SLA расшифровывается как Service Level Agreement, дословно Соглашение об уровне сервиса. Термин SLA пришел из сферы IT, но теперь применяется далеко за ее пределами.
Впервые понятие SLA было введено в так называемой библиотеке инфраструктуры информационных технологий ITIL. В ней описаны стандарты построения и обслуживания IT-инфраструктуры. И, в частности, сказано, что любой сервисный процесс должен осуществляться по определенным правилам, которые имеют некий уровень − он как раз и фиксируется в SLA.
Роль Service Level Agreement для бизнеса
Если компания при выполнении процессов обслуживания клиентов опускается ниже установленных показателей, значит, она плохо работает. Таким образом, SLA − это универсальный инструмент оценки уровня сервиса любого бизнеса как в B2C, так и в B2B. Правда, применяется далеко не повсеместно. Почему?
- Во-первых, в России пока еще не очень развита культура сервисного обслуживания.
- Во-вторых, мало кто глубоко погружается в этот вопрос, и в итоге большинство работает без регламентированных правил.
На самом деле Service Level Agreement дает значимое конкурентное преимущество тому, кто его заключает.
Для примера возьмем интернет-магазин одежды. Возможно, вы найдете один и тот же костюм по одинаковой цене на разных сайтах, но закажете скорее всего там, где будет самая быстрая, дешевая и удобная доставка. Далее курьер привезет вещи на примерку, но представим, что они вам не подошли, и вы запускаете процедуру возврата. В этот момент начинается следующий процесс обслуживания со стороны интернет-магазина. И вы, наверняка, останетесь довольны, если все будет сделано опять же быстро и без финансовых потерь.
Гарантировать соблюдение всех процедур на определенном уровне может только та компания, у которой каждый шаг регламентирован Соглашением об уровне сервиса. Это может быть внутренний документ, который устанавливает правила обслуживания в этой организации.
Принимая Соглашение об уровне сервиса, компания заявляет о своих стандартах обслуживания, которым следует. Сотрудники, взаимодействующие с клиентами, могут подписывать SLA в рамках своего трудового договора (как приложение к нему или как отдельное распоряжение). Оператор колл-центра или менеджер по работе с клиентами должен знать стандарты обслуживания, принятые в организации, и четко их соблюдать. По сути, он тем самым исполняет свои трудовые обязанности, но с определенным уровнем качества.
Структура классического SLA описана в ITIL, при этом она довольно универсальна и может быть применима в абсолютно любом бизнесе. Какие разделы включает Соглашение об уровне сервиса?
Что описывается в договоре?
Каталог услуг
Прежде всего, SLA должно содержать каталог услуг, которые компания оказывает клиенту. В случае с товарами в качестве одной из таких услуг всегда является доставка. Все ее условия должны быть прописаны в SLA: география, сроки, цена и пр.
Помимо общих параметров, у каждой компании в зависимости от специфики деятельности будут и специфические позиции. Скажем, для интернет-магазина одежды сюда будет относиться время ожидания курьера, пока клиент примерит заказ. А для интернет-магазина электроники − условия доставки до подъезда и подъема на этаж.
Какова сумма заказа для бесплатной доставки, есть ли возможность получить товар в четко обозначенный час, можно ли изменить время и место встречи курьера и пр. Вопросов у клиентов может быть масса, и все решения должны изначально содержаться в SLA. Потребитель должен четко понимать, что он получает за свои деньги и за что надо дополнительно заплатить в случае необходимости. К примеру, можно ли при поставках оборудования на предприятие за отдельную плату заказать сборку и настройку.
Время оказания услуг
Далее компания сама для себя устанавливает время оказания услуг и доводит это до сведения клиентов, чтобы не оказалось, что человек будет названивать в техподдержку среди ночи, тогда как она начинает работать только в 9 утра.
Кстати, в случае с услугами важно четко обозначить, что в них входит, а что нет. К примеру, в сфере ИТ в договоре указывается, сколько рабочих мест пользователей и какая конкретно техника обслуживается. А если сотрудник принесет свой личный ноутбук, то он не входит в договор. Не должно возникать недосказанности и разночтений. Это позволит избежать взаимных претензий.
Параметры сервисного процесса
В этом разделе несколько принципиально важных показателей, которые опять-таки универсальны для любого бизнеса. Первый – это время реакции на заявку клиента.
Понятно, что чем быстрее компания реагирует, тем более привлекательной она выглядит в глазах клиента. Допустим, вы обратились за коммерческим предложением в несколько фирм. Та, которая вышлет его первой, скорее попадет в зону вашего внимания. Правильно, если у компании в SLA написано, что на заявку клиента нужно отвечать, предположим, в течение часа (или иного времени, которое подходит для вашего бизнеса).
Второй параметр − это время решения заявки клиента. Он актуален для сложных услуг. Если вы запросили стоимость офисной бумаги, она может быть направлена вам в течение нескольких минут. А если вы в рамках сервисного договора обращаетесь, к примеру, в юридическую фирму с просьбой проверить своего контрагента, то надо понимать, что это займет некоторое время. Сколько конкретно − и должно быть написано в SLA.
Правильный порядок действий клиентоориентированной компании: после получения заявки она в оговоренный срок реагирует на нее и сообщает, что задача будет решена за такое-то время. Тогда человек понимает, что его заявка получена и взята в работу. По истечении обозначенного срока задача клиента должна быть решена. Если это вовремя не сделано, значит, компания нарушила условия SLA и может понести штрафные санкции, заплатить неустойку или не получить часть положенной премии.
Третий параметр зависит в том числе от самого клиента. Предположим, вы записались на прием к врачу, он вас принял вовремя и дал рекомендации − сдать анализы, принимать лекарства и соблюдать режим. Если вы все это выполните, то почувствуете себя лучше. Врач обозначил время решения проблемы, но и на пациента возложил некую ответственность. Но возьмем ситуацию, когда больной ничего не сделал. Пришел на повторный прием, где врач снова дал ему рекомендации и отпустил еще на неделю. Тем самым он отложил решение проблемы.
Другой пример: вы заказали замерщика пластиковых окон, он приехал, но вас не оказалось дома. Компания должна определить, сколько еще раз она сможет отправить к вам замерщика бесплатно и с какого момента вам придется за это заплатить.
Назовем этот параметр временем возврата заявки. Он тоже должен содержаться в SLA вместе с описанием условий, при которых заявка может откладываться и возвращаться в работу, и количеством раз такой отсрочки. Исполнитель не несет ответственности в случае, если заказчик сам не выполнил свою часть обязательств. В некотором смысле этот параметр защищает права исполнителя.
Условия оплаты
Еще в SLA должны быть зафиксированы условия оплаты за предоставляемый сервис − не только стоимость услуг, но и момент ее списания (предоплата или постоплата) и правила возврата при отмене заказа. Скажем, вы бронируете номер в отеле. Цена проживания тут же списывается с вашей карты. Потом вы отменили поездку. Если оповестите отель заранее, он вернет все деньги. А если, скажем, менее чем за сутки до въезда − за вычетом некой удержанной суммы. Эта процедура тоже регулируется SLA.
Правила разрешения споров
Также в Соглашении об уровне сервиса должны быть сформулированы правила разрешения конфликтных и спорных ситуаций. Что делать, если вам привезли ботинки не того цвета, такси не доставило вас вовремя или пицца опоздала к ужину. А может быть, вам обещали восстановить доступ в интернет и сообщили о решении проблемы, а интернета как не было, так и нет. Все эти моменты надо предусмотреть.
Чек-лист по составлению Соглашения об уровне сервиса
Итак, грамотное SLA включает как минимум семь ключевых параметров:
- Список и состав предоставляемых услуг
- Время и география – когда и где обслуживаем клиентов
- Время реакции на заявку – наш первый ответ клиенту
- Время решения заявки – когда клиент получит результат
- Время возврата отложенной заявки
- Порядок оплаты услуг клиентом
- Правила решения спорных ситуаций
Если компания не устанавливает значения этих параметров, значит, у нее нет стандартов обслуживания клиентов.
К примеру, в компании Информатика и Сервис SLA состоит из универсальной части и индивидуальной (в которой могут содержаться не все услуги, а только некоторые из них) и является приложением к договору с каждым конкретным клиентом. В нем расписаны все наши услуги, стоимость и порядок их оказания. Это универсальная формула для всех видов бизнеса. Берите и пользуйтесь.
Автоматизация процессов обслуживания клиентов
Это следующий шаг для тех, кто уже разработал стандарты обслуживания и заинтересован в том, чтобы контролировать их исполнение и улучшать. Для этого существует целый класс программных продуктов − Help Desk или Service Desk. Будем оперировать вторым понятием, которое более функционально.
Каждый шаг сервисного процесса должен быть интегрирован и автоматизирован в системе Service Desk. Как это выглядит?
Все начинается с подачи заявки клиентом – это может быть электронная форма на сайте, письмо или звонок. Новая заявка немедленно регистрируется в журнале учета заявок Service Desk. Кстати, в самом простом виде ею может выступать даже обычный Excel, если все заявки собираются там.
Под Service Desk может пониматься любая программа, в которой тем или иным способом регистрируются, обрабатываются и анализируются клиентские запросы.
После этого система должна помогать выполнять процесс обслуживания клиентов в соответствии с параметрами, которые закреплены в SLA. Для начала − сообщить клиенту, что его заявка получена и будет обработана за конкретное время ответственным исполнителем.
Желательно, чтобы исполнитель тоже назначался в автоматическом режиме с учетом профиля его деятельности, компетенций, загруженности и пр.
Обычно все заявки клиентов попадают в единую очередь, доступ к которой имеют клиентские менеджеры, которые вручную разбирают запросы, реагируют на них и распределяют по ответственным за решение сотрудникам. Сам порядок этих действий и параметры процесса должны быть закреплены во внутреннем SLA компании. И если, к примеру, менеджер взял в обработку заявку, но вовремя не сообщил об этом клиенту, система должна напомнить ему об этом.
В идеале, повторим, Service Desk сама должна автоматически реагировать на заявку, назначать компетентного исполнителя и сообщать ему, что он должен решить запрос клиента к определенной дате.
Далее начинается этап решения заявки, то есть задачи клиента. Идеальная система автоматизации обслуживания клиентов должна содержать в себе базу знаний по решению различных запросов. Тогда ответственный специалист может к ней обратиться и ускорить весь процесс.
Допустим, вы подбираете тур в Африку. У хорошей турфирмы сразу есть база всех отелей с ценами и вариантами размещения. Менеджеру не надо тратить время на поиск этой информации, она вся под руками. Подробнее о базе знаний можете почитать .
Следующий эволюционный этап автоматизации сервисного обслуживания − это когда "искусственный интеллект" внутри системы Service Desk, получая запрос от клиента, научится его правильным образом читать, сопоставлять с данными из базы знаний и тут же отправлять в автоматическом режиме ответ клиенту. Это то, к чему должны стремиться все сервисные системы − работать автономно, без менеджеров и исполнителей.
Конечно, это подходит для решения типовых задач. Более сложные еще долго будут требовать участия компетентных специалистов.
На этапе работы над заявкой клиента система автоматизации обязательно должна сообщать исполнителю об оставшемся времени до истечения срока решения заявки. Ведь если он не успеет вовремя, это будет нарушением SLA. И если в договоре с клиентом зафиксированы штрафные санкции за такое нарушение, то компания-исполнитель может понести убытки за низкое качество обслуживания клиентов, что справедливо. Service Desk должна фиксировать такие нарушения по каждой заявки, а руководители должны получать отчеты и сводную информацию о качестве услуг в соответствии с принятыми стандартами обслуживания и закрепленными в SLA.
При возникновении спорной ситуации, когда исполнитель считает заявку клиента выполненной вовремя и качественно, а клиент остался недоволен и заявляет о своем несогласии с оказанной услугой, система Service Desk должна заново открыть заявку и запустить процесс ее решения. Все эти этапы должны отражаться в отчетах, по которым формируется рейтинг как конкретного исполнителя, так и компании в целом. У клиента должна быть возможность поставить оценку качества обслуживания через систему автоматизации.
Например, любое мобильное приложение службы такси по окончании поездки предлагает вам оценить водителя и уровень сервиса. Если вы поставите низкую оценку, то приложение поинтересуется причинами. Любая система Service Desk тоже должна предоставлять такую возможность клиенту. Ну и, в идеале, система автоматизации должна быть интегрирована с сервисами оплаты или, по крайней мере, напоминать о формировании счетов или учитывать внесенный пользователем аванс.
Решение для автоматизации процессов обслуживания
9 октября 2017 года компания Информатика и Сервис выпустила новое приложение для Битрикс24 − оно называется Admin24 - Service Desk и помогает бизнес-пользователям Битрикс24 существенно улучшить качество обслуживания клиентов.
В Битрикс24 есть модуль задач (более подробно о нем можно прочитать ), который позволяет создать задачу, назначить исполнителя, указать крайний срок выполнения и пр. Но все это делается в ручном режиме. Когда компания обслуживает большое количество клиентов, важно, чтобы их заявки регистрировались в системе автоматически, чтобы так же автоматически назначались исполнители в соответствии с каталогом услуг и чтобы система следила за исполнением параметров SLA. В штатных возможностях Битрикс24 этого нет. Но благодаря новому приложению Admin24 такой функционал стал доступен.
В нашем приложении можно сформировать простейший каталог услуг. За каждой из них закрепить одного или нескольких ответственных исполнителей. Также в первых версиях приложения Admin24 можно указать три важнейших параметра SLA − время реакции на заявку клиента, время ее выполнения и срок автовозврата заявки (для случаев, когда она по тем или иным причинам была отложена исполнителем). При этом, для расчета всех параметров может применяться только то время, которое вы укажете как рабочее в настройках самого Битрикс24.
Еще в приложении можно указать реквизиты компании, чтобы соблюсти требования федерального закона 152-ФЗ «О персональных данных». Как вы знаете, клиент, отправляя заявку, передает вам свои персональные данные (имя, фамилию, телефон). По закону он должен дать на это согласие.
Admin24 - Service Desk автоматически создает веб-форму заявки, в которой клиент может выбрать услугу, оставить свои контакты и поставить галочку, что соглашается на передачу и обработку своих персональных данных.
Далее заявка клиента попадает в виде задачи в специально созданную в Битрикс24 группу Admin24 - Service Desk и автоматически назначается тем ответственным исполнителям, которые были определены на этапе формирования каталога услуг при установке и настройке приложения. Настройки можно изменить в любой удобный момент, и это не отразится на ранее полученных заявках.
В задаче для исполнителя сразу указаны контактные данные клиента, текст обращения, а также услуга, по которой поступила заявка. Если этот клиент уже зарегистрирован в CRM Битрикс24, то задача автоматически прикрепляется к его карточке. Получается, что ответственный менеджер отдела продаж увидит, с какими запросами обратился его клиент в сервисный отдел, и сможет подумать, какие еще продукты или услуги продать клиенту дополнительно. В перспективе в Admin24 можно будет автоматически формировать и отправлять счета на оплату из CRM Битрикс24.
В настоящее время реализован минимальный функционал Admin24 - Service Desk , который уже позволяет использовать Битрикс24 как систему автоматизации обслуживания клиентов. Все параметры SLA по каждой заявке фиксируются, и руководитель в специальном отчете видит, сколько заявок не решены в положенный срок, на сколько из них реагировали не вовремя. У руководителя появляется возможность принимать решения на основе этих отчетов, проводить работу над ошибками и повышать качество обслуживания. Этот процесс должен быть непрерывным.
Таким образом, приложение Admin24 - Service Desk позволяет автоматизировать процесс выполнения заявок и обслуживать клиентов на основе SLA. Любая компания, которая использует Битрикс24, может начать обслуживать своих клиентов на основе Соглашения об уровне сервиса. То есть сформировать свои собственные стандарты обслуживания клиентов и постоянно их улучшать.
Увеличение объемов ИТ-аутсорсинга в России приводит к необходимости однозначно фиксировать договоренности сторон, качество предоставляемых услуг, сроки, цели сотрудничества, его продолжительность и экономическую эффективность, условия оплаты и расторжения, гарантии, размеры и формы компенсаций и пр. Основным и единственным инструментом для регулирования вопросов предоставления качества ИТ-услуг остается 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
Из всего многообразия возможных ИТ-сервисов, для предоставления или получения которых необходимо 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.ru
Согласно Википедии Соглашение об уровне обслуживания (перевод Service Level Agreement SLA) - термин методологии ITIL, обозначающий формальный договор между заказчиком услуги и её поставщиком, содержащий описание услуги, права и обязанности сторон и согласованный уровень качества предоставления данной услуги. Процесс SLA описан в книге ITIL Проектирование услуг (Service Design).
Как правило, SLA является приложением к основному договору с поставщиком (оператором) услуги и описывает нюансы ее использования, роли и ответственность на всех этапах от заказа до прекращения использования. Нередко, в виду сложности структуры SLA, стороны допускают при его составлении, избежать их можно обратившись к квалифицированным специалистам.
Состав соглашения об уровне оказываемых услуг (SLA)
Типовое соглашение об уровне сервиса (SLA) должно содержать следующие разделы:
- Контактные данные сторон, вовлеченных в соглашение, и срок его действия
- Описание услуги
- Техническая информация об услуге
- Поддерживаемое оператором абонентское оборудование
- Уровень и качество обслуживания
- Средства мониторинга и отчеты SLA
- Центр технической поддержки
- Механизм резервирования и восстановления услуги
- Нарушения обслуживания и компенсации
- Тарифы и выставление счетов
- Процесс улучшения SLA
- Порядок прекращения оказания услуги
Пример SLA
Подробнее показатели и примеры соглашений об уровне сервиса SLA рассмотрены в стандарте ITU-T M.3342 и TM Forum SLA Management Handbook. Вы можете получить шаблон SLA для услуги виртуальной частной сети (VPN), отправив заявку.
На что обратить внимание при составлении договора SLA
При разработке SLA соглашения об уровне оказываемых услуг необходимо определить:
- Перечень ключевых показателей: типовое SLA должно содержать технологические (KPI) и организационные (KQI) показатели услуги. Каждый показатель должен однозначно трактоваться и иметь согласованную формулу для его расчета.
- Целевые значения показателей: для каждого показателя должно быть определено целевое значение исходя из потребностей бизнеса, предоставления информационных и телекоммуникационных услуг. Например, целевые значения услуги VPN определяются исходя из требований вышележащих сервисов. При использовании дополнительных средств шифрования каналов данная задача становится не тривиальной и требует лабораторных изысканий с использованием специализированных средств или определения данных показателей эмпирическим путем (методом «тыка»).
- Средства контроля и отчетности: Для каждого показателя должна быть определена методика измерения и средства контроля его значений. Согласование является важным моментом при подготовке SLA соглашения об уровне оказываемых услуг. Отчеты SLA должны формироваться в автоматическом режиме .
Компенсации и скидки: Компенсация за ненадлежащее выполнение SLA является не самой целью для клиента. Данный момент является средством управления взаимоотношениями с поставщиком. Клиент должен быть уверен, что оператор сделает все возможное для достижения целевых значений показателей качества оказываемых услуг. При этом клиент должен быть готов заплатить за «страховку», чтобы при наступлении «страхового случая» получить компенсацию.
На самом деле, SLA - это предмет переговоров. Здесь много параметров, которые можно изменять. И цена конкретного соглашения может сильно отличаться в зависимости от взятых обязательств поставщика. Поэтому привлечение экспертов отрасли и квалифицированных юристов для составления SLA позволит компании и быть уверенной в правильности принятия решения при выборе поставщика услуг.
Мы проводим существующих договоров в рамках внедрения системы мониторинга качества услуг wiSLA и составляем шаблоны SLA на услуги связи и мониторинг инфраструктуры. От качества проработки соглашения SLA зависят не только компенсации, SLA является основой доверительных партнерских отношений между оператором связи и его клиентами.