ИТ-инфраструктура – живая, постоянно развивающаяся экосистема, которая нуждается в непрерывной поддержке, техническом обслуживании и модернизации. Большинство заказчиков предпочитают отдавать сопровождение ИТ-систем профессионалам – системным интеграторам – и контролировать процесс со стороны.
При этом, естественно, заказчикам непросто отслеживать качество услуг, предоставляемых интегратором. Не всегда удается выстроить контрольные параметры, позволяющие правильно оценить работу интегратора и непрерывно совершенствовать уровень сервиса. Чтобы сделать обслуживание более прозрачным и избежать конфликтных ситуаций в процессе предоставления услуг, интеграторы предпочитают заключать с клиентом SLA (Service Level Agreement) – соглашение об уровне сервиса.
Вам будет интересно:Интернет вещей: главная уязвимость — устаревшие устройства
Слово из трех букв – SLA
SLA – развернутое приложение к договору на оказание услуг. Термин Service Level Agreement пришел из ИТ-сферы и постепенно прижился в других отраслевых бизнесах. SLA – важнейший компонент любого контракта на аутсорсинг, который обычно регламентирует порядок и качество предоставления услуг клиенту и направлен на предотвращение инцидентов при эксплуатации бизнес-приложений.
Вам будет интересно:Выбираем доступный видеоредактор
Соглашение об уровне обслуживания в первую очередь фиксирует порядок и режим предоставления услуг, а также разграничивает зоны ответственности поставщика и заказчика.
Во-вторых, SLA определяет гарантированные целевые показатели для оценки качества услуг. Другими словами, интегратор берет на себя обязательство построить сервисный процесс таким образом, чтобы не опускаться ниже согласованных в договоре стандартов или KPI.
И наконец, в-третьих, что важнее всего для клиента, SLA закрепляет права и обязанности сторон, в том числе определяет размер штрафных санкций на случай, если указанный в соглашении уровень обслуживания не будет достигнут. Таким образом, заказчик оказывается защищен от некачественной работы интегратора, а поставщик услуг – от неподтвержденных претензий к качеству сервиса.
Service Level Agreement заключается обычно после внедрения решения и перед началом технического обслуживания клиента.
Как выбрать формат SLA
Подходящий формат SLA определяется совместным решением интегратора и клиента и базируется на спецификациях поддерживаемой ИТ-системы, внутренних процессах заказчика, технических возможностях интегратора и других факторах, которые могут повлиять на качество обслуживания.
Конечно, ключевые стандарты проведения услуг – управление инцидентами, проверка неавторизованных изменений, срок недоступности ИТ-системы в случае аварийного восстановления – в большинстве своем одинаковы для всех заказчиков. Но этих показателей часто бывает недостаточно, поэтому система норм и требований формируется индивидуально для каждого клиента и содержит множество дополнительных измеряемых параметров и условий предоставления услуг. Подробное соглашение может охватывать управление рисками, спецификации безопасности, статистику производительности, вопросы безопасности и шифрования конфиденциальной информации.
При заключении соглашения необходимо обратить внимание на адекватность требований стоимости обслуживания. Это поможет избежать недопонимания с обеих сторон. В идеале SLA стоит также согласовывать с технологическими или бизнес-целями взаимодействия – их несоответствие может негативно сказаться на качестве услуг и клиентском опыте.
Какие KPI стоит включать в SLA
SLA должно включать не только описание осуществляемого интегратором обслуживания, но и показатели, по которым измеряются качество оказанных услуг, обязанности и ответственность каждой стороны соглашения.
Зафиксированные в соглашении целевые значения должны быть достижимы, поэтому при заключении SLA важно понимать:
а) какие сроки и показатели интегратор в состоянии соблюдать;
б) какой процесс стоит за соблюдением этих сроков и показателей.
Иными словами, метрики должны быть универсальными и легко измеримыми. Обычно такие KPI включают:
• время реакции на проблему пользователя;
• среднее количество сбоев за определенный период и время, затрачиваемое на их устранение;
• количество решенных проблем;
• число замечаний, жалоб пользователей;
• критическое время недоступности сервиса;
• число или отсутствие системно-технических сбоев в работе системы.
Естественно, гарантироваться должен уровень не ниже согласованного в документе. Другими словами, если SLA предусматривает двухчасовую реакцию на обращение клиента, основанием для штрафных санкций может служить любое превышение срока ожидания ответа в 2 часа. Исключением являются случаи отклонения от допустимого KPI, предусмотренные в соглашении (например, время решения проблемы с отказом оборудования может индексироваться, если ситуация зависит не от интегратора, а от провайдера).
При этом оценка работы интегратора обычно осуществляется на основании периодической отчетности, опросов клиентов и других инструментов, определенных в соглашении. Как правило, самые агрессивные KPI устанавливают заказчики, у которых от работы ИТ-инфраструктуры зависят финансовые результаты: например, предприятия из финансового сектора или области электронной коммерции могут указать время безотказности системы в 99,999%. И это нормально для тех, кто обрабатывает заявки на миллионы долларов в час.
Кто за что отвечает
Другой вопрос, который остро стоит перед заключающими договор, – определение границ ответственности обеих сторон. Нужно четко понимать, кто будет отвечать за работоспособность программной части обслуживаемой системы, а кто за работоспособность системно-технических средств. В противном случае при подаче нетиповой заявки (например, система недоступна по причине выхода из строя серверного оборудования, за обслуживание которого отвечает сторонняя организация) клиент обратится с претензиями к интегратору, который в данной ситуации не может ничего предпринять. SLA позволяет разграничить область взаимодействия поставщика услуг с клиентом заранее определенными рамками, что, очевидно, смягчит напряженность в решении спорных вопросов о качестве услуг.
Обычно к помощи интегратора клиент обращается в случаях, когда необходима консультация по поводу использования системы, устранения проблем функционирования системы, изменения ее функциональности или улучшения опций ПО и доработки существующих функций, например, создаваемых в системе отчетов.
Что нужно «считывать» из договоров SLA
Подводя итог, при заключении договора SLA следует обязательно включить в него согласованные показатели:
• Метрики оценки качества предоставляемой услуги. Ключевые показатели – технологические (KPI) и организационные (KQI) – и их целевые значения должны трактоваться однозначно и иметь согласованную формулу для его расчета.
• Компенсации. Они необходимы в качестве меры контроля и штрафных санкций за нарушение условий соглашения. Важно обратить внимание не столько на размер компенсации со стороны поставщика услуги, сколько на причины их выплат.
• Отчетность. В документе должны быть детально прописаны способы/формы отчетности для поставщика услуги, согласованы инструменты мониторинга показателей качества.
Все это позволит защитить как клиента, так и поставщика от неоправданных ожиданий.
При этом большинство SLA учитывают потребности клиента только на момент подписания соглашения. Но ведь многие компании резко меняются со временем! Поэтому при заключении SLA не забывайте предусмотреть интервалы, через которые соглашение будет пересматриваться, отвечая динамичным требованиям бизнеса. Пересмотр SLA раз в год – это неплохой задел для выстраивания гармоничных и укрепляющихся отношений между клиентом и ИТ-подрядчиком.
