Как написать хороший sla

Время на прочтение
14 мин

Количество просмотров 154K

Как написать хороший SLA (Service Level Agreement, оно же Соглашение об уровне сервиса). И какой SLA будет хорошим.

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

Я буду оперировать названием SLA, Service Level Agreement, оно же Соглашение об уровне сервиса. Пришло оно из ITIL/ITSM и прижилось. Этот документ является краеугольным камнем в текущих подходах к осуществлению функций IT. Также он является одним из ключевых, если мы либо хотим нанять внешнего исполнителя для каких-нибудь услуг, либо хотим внутренние подразделения сделать максимально автономными, то есть по сути относиться к ним как к внутреннему аутсорсеру. И хотя подходы ITSM несколько более универсальны и применять их можно с некоторой выдумкой даже довольно далеко за рамками IT, в дальнейшем изложении я буду приводить в примеры ситуацию, когда у нас есть некоторая IT система и сервис — это её сопровождение. Ну просто потому что такая задача типична и встречается повсеместно. Аналогично можно написать SLA для любой другой деятельности, поменяются только список услуг да критерии оценки.

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

Вводная (определительная) часть SLA

В водной части SLA, и я не зря назвал её определительной, неплохо было бы определить, о чём вообще идёт речь.

Лучше всего начать SLA с глоссария, краткого описания системы и ролей участников процесса. Указываем название системы, на основе какого продукта от какого производителя она сделана, если в основе коробочный продукт, или на каких технологиях основана, если самопал. Обычные участники — пользователи, ключевые пользователи, сотрудники HelpDesk (первой линии поддержки), сотрудники второй, третьей (и так далее) линий поддержки, можно указать названия подразделений компании, вовлечённых в процесс, и перечислить какие роли выполняют сотрудники этих подразделений.

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

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

Подводя итог, общая часть SLA должна чётко определить сервис, который мы собираемся регулировать остальной частью документа. Общая часть должна дать понять, что в рамках данного SLA должно делаться, а что не должно. Если есть неопределённости, то дорабатываем описание. В идеале сторонний человек в теме (например, сотрудник профильной консалтинговой компании) должен после прочтения сказать «да, всё понятно!»

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

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

Какой SLA является хорошим?

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

Почему к SLA такое трепетное отношение? Почему из кучи документов, описывающих регламенты работ и прочие политики внутренней кухни IT подразделений, именно SLA стоит особняком? Да потому что SLA является регулирующим документом. Этот документ не только определяет, что и как у нас будет сервисом (эта часть как раз часто дублирует другие регламентные документы), а определяет куда мы будем смотреть в процессе предоставления сервиса и что мы хотим там увидеть. Это существенным образом определяет весь характер работ. А искусство, с каким подобраны метрики процесса и, что самое важное, целевые их значения — вот что будет определять как будет оказываться сервис. Это позволяет контролировать процесс.

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

Выбор метрик для SLA

Много великих умов человечества посвятили массу времени и внимания придумыванию метрик. Обычно не составляет особого труда выбрать такие метрики, которые подойдут в конкретном случае. Знание и понимание предметной области тут является ключевым. Интересно, что некоторые процессы не поддаются вводу метрик. Например, работу программиста нельзя описать хорошими метриками, любая из них может быть перевыполнена программистом в ущерб делу, то есть дискредитирована. И в силу особенностей профессии, любая метрика непременно будет дискредитирована. Но об этом как-нибудь в другой раз. Для поддержки IT-систем всё несколько проще. Часто берут время реакции (иногда подразумевая под ним время до начала обработки запроса) и целевое время для решения запроса. Если в вашей организации исторически сложились другие общепринятые параметры, то возьмите их. Ознакомиться с мировым опытом и подобрать себе метрики можно погуглив на ключевые слова «SLA» и «метрика».

Что тут важно. Не вдаваясь в подробности (это тема для отдельной статьи), метрики должны обладать следующим качествами:
(1) отражать качество предоставления сервиса,
(2) быть легко измеримыми,
(3) быть по возможности универсальными (чтобы использовать во всех своих SLA),
(4) их не должно быть много.

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

И, наконец, последнее по порядку (но не по важности):
(5) метрика должна зависеть только от работы исполнителя.

Если корреляция метрики с работой исполнителя будет слабая, то метрика не будет работать — контроль потерян, SLA не работает.

Приведу пример плохой метрики. Время доступности конкретной IT-системы 99,99% является плохой метрикой для работы HelpDesk. Потому что HelpDesk не влияет на время простоя систем от слова «никак». То есть, если система «упала», то HelpDesk может только максимально оперативно передать информацию тому администратору, кто может систему «поднять». А сколько это займёт времени (и будет ли там вообще кто-либо суетиться) от HelpDesk-а не зависит. Наказывать HelpDesk за чью-то неоперативную работу — это жестоко и бессмысленно. Единственное, чего этим можно будет добиться, что HelpDesk на подобный SLA положит с прибором.

Значения метрик

Теперь я хочу показать, как грамотно подойти к выбору значений метрик.

Типичная ошибка выглядит вот как. Описываю ситуацию. Пусть у нас есть довольно большая система (например, какая-нибудь ERP), и на её поддержке работают:

1. HelpDesk (он же 1й уровень поддержки), принимающий обращения от всех пользователей компании по телефону, почте и интранету, оформляющий обращения в инциденты и переводящий инциденты в специализированные группы поддержки 2-го уровня,
2. Группа поддержки 2-го уровня из аналитиков, знающих эту систему с точки зрения функционала, которые могут разобрать инцидент, помочь пользователям и выявить ошибки системы в коде/данных,
3. Группа поддержки 3-го уровня из разработчиков, которые умеют исправить код/данные в системе и привлечь вендора базового ПО в случае необходимости,
4. Вендор базового ПО является в этой схеме 4-м уровнем поддержки. На этом же уровне могут фигурировать другие подразделения компании типа сетевиков, инфраструктуры и т.п.

Если в Вашем случае эта система выглядит проще, не надо переживать. Я объясню принцип. А чем проще система, тем только легче её регулировать.

Мы пишем в SLA, что проблема критичного приоритета нашей системы должна решаться, скажем, за сутки. Аргументируем это тем, что пользователи хотят, чтобы за сутки проблема была решена. Мы их спрашивали, и они подтвердили. Это основная метрика в нашем SLA. Хорошо ли это или плохо? Рассмотрим с разных сторон.

HelpDesk в любом случае успеет сделать всё, что от него зависит даже не за сутки, а за час максимум. То есть в процессе телефонного разговора будет оформлен инцидент, заданы уточняющие вопросы, информация зафиксирована и отправлена на 2-й уровень. Час — это так, с запасом. Поэтому HelpDesk не обращает никакого внимания на метрики в SLA. Главное, чтобы всё, прилетевшее сегодня, сегодня же и улетело, и все SLA будут выполнены. Но они так всегда работают.

Теперь 2-й уровень получил инцидент (может напрямую, может из HelpDesk), и до конца дня есть время, чтобы с инцидентом разобраться. Не каждый инцидент может быть за такое время решён, но большая часть действительно за день решается, особенно критичного приоритета. Правда, если инцидент проболтался забытым до вечера в HelpDesk-е, то времени на его решение не осталось. При этом нарушит метрику 2-й уровень, а виноват-то на самом деле был HelpDesk…

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

Теперь 3-й уровень в лице разработчиков, если ещё не разошёлся по домам, имеет дилемму — поработать ударно в ночь или гарантированно нарушить SLA и заняться проблемой утром следующего рабочего дня. В случае ручного педалирования ситуации конечно первый вариант сработает, но штатной такую работу называть не хочется. Потому что с таким подходом срочное прилетает всегда к вечеру. Это итог ударной (и, что особенно важно, хорошей) работы коллег со 2-го уровня.

Разбор полётов. Что мы видим в результах в свете нашего SLA? Для HelpDesk-а и 3-го уровня SLA не работает, работает только для 2-го.

Что будет, если мы увеличим целевое время решения до недели? Теперь можно начать требовать исполнения такого SLA с 3-го уровня. Но зато для 2-го уровня такой SLA работать перестал — чего суетиться, завтра успеем. Или послезавтра. В результате на 3-й уровень проблемы станут попадать в последний день отведённой недели, 3-й уровень этим фактом возмутится и (если здравый смысл внезапно победит) неделя из SLA будет поделена на 2 дня работы 2-го уровня и 3 дня работы 3-го или ещё как-нибудь. Ну и 2-й уровень конечно расслабится, ведь времени, которое ему можно терять попусту, явно стало больше. Зато HelpDesk теперь на SLA не смотрит совсем, они такой SLA не могут нарушить даже если захотят. Им пользователи голову раньше открутят. И общее время решения проблем станет больше. Как-то не очень получается.

А что делать, чтобы SLA начал работать для HelpDesk? Наверное уменьшать время. До одного часа. Но тогда и 2-й и 3-й уровни перестанут попадать в SLA в принципе. И они перестанут в SLA смотреть совсем, потому что там с их точки зрения глупости написаны. И ещё постепенно все уволятся, потому что не могут выполнять свою работу хорошо, а этого на самом деле никто не любит.

Что же делать? Делать выводы. Если мы хотим контроль, то надо выделить целевое время работ на каждом уровне поддержки. И дать на работу HelpDesk-у час, 2-му уровню день, а 3-му три дня. За это время каждый должен выполнить свою задачу. А пока задачу решают другие, один счётчик тикать перестаёт, другой включается. Теперь у нас каждый следит за своим временем и не теряет его попусту. Полный контроль. При привлечении дополнительного уровня поддержки общее время должно увеличиваться, отражая глубину выявленной проблемы. Если надо кого-то интенсифицировать, то можно сделать это адресно. Например, если в самом деле надо вписаться в сутки на всё про всё, то делим их на 30 минут для 1-го уровня, 4 часа для второго и 19 с половиной для третьего. Это может оказаться излишне жёсткими требованиями в каком-то случае, но о вредных последствиях излишне жёстких требований я поясню чуть позже. Зато теперь у нас в SLA есть контроль и он работает, так как метрика позволяет легко выявить, кто не выполняет свою часть работы хорошо. Если пишете многоуровневый SLA, то всегда указывайте метрики отдельно для каждого уровня.

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

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

Чем опасны излишние требования

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

Пример №1. Предположим, что какой-то вид запросов на обслуживание в среднем решается часа за 4. Также нам известно, что исполнитель с высоким уровнем экспертизы может решать такие запросы за 2 часа. Что будет, если мы в SLA напишем 2 часа вместо 4? Это приведёт к тому, что исполнитель должен быть экспертом, значит станет более дорогим. Плюс проблемы с его мотивацией в будущем. Потому что с одной стороны эксперту будет скучно заниматься одним и тем же, а с другой стороны есть куча мест, куда его будут усиленно звать. По моим многочисленным наблюдениям цена услуги увеличивается в полтора-два раза.

Пример №2. Что будет, если в SLA в той же ситуации написать 1 час (или 1 минуту, что в данном контексте одно и то же), то есть сделать время нереалистичным? К предыдущему увеличению стоимости смело добавляйте величину предполагаемых штрафов за просрочку и умножайте результат на коэфициент риска, равный, скажем, 1,5-2. И, что самое плохое в данной ситуации, SLA перестаёт работать. Не надо так делать в здравом рассудке.

Пример №3. Хотим вместо режима 8х5 (8 часов по рабочим дням) получить режим 24х7. Ценник тут же увеличивается в два-три раза. И это только в том случае, если можно обойтись дежурной сменой, которая будет перекрывать ночь/выходные и вызванивать реальных исполнителей в случае чего. Если же нужна реальная постоянная работа в режиме 24х7, то ценник будет выше в пять раз, если не больше. Почему? Потому что три смены и выходные/праздники, да подмена на отпуска/больничные. А ещё квалифицированные кадры могут отказаться работать по нестандартному графику, и этот разрыв ожиданий придётся тоже лечить деньгами. Точно ли нужен 24х7?

Пример №4. Хотим постоянного присутствия исполнителя в офисе, чтобы было видно, как он работает и не работает ли — ах! — на сторону? Да, теперь он действительно не может больше помогать коллегам, участвовать параллельно в других проектах, а также не может быть сотрудником из регионального офиса. В конце концов исполнитель будет обязан соблюдать наш дресс-код и терять время на дорогу к нам. Итого раза в два будет дороже. Попутно мы перекрыли себе возможность использовать дополнительные ресурсы во время пиковых нагрузок и привлечение экспертов нужной квалификации по мере надобности, что происходило бы само собой в случае удалённой работы исполнителя. А может и не происходило бы, но теперь этого точно не будет.

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

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

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

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

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

Заключительные пожелания

Дополните SLA уместными ссылками на другие документы, описывающие процесс: политиками и регламентами. Не помешает указать, какие системы ведения запросов (обращений, инцидентов, проблем) используются, привести ссылки на регламенты работы с ними.

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

Что делать, если систем много. Писать свой SLA на каждую — получится совершенно запутанный зоопарк, нужно унифицировать. Полезно было бы сразу метрики из SLA и их значения сделать универсальными, чтобы не изобретать велосипед для каждой IT-системы в компании, да и в целом так проще отслеживать, что происходит вокруг, сравнивать ситуацию по разным системам. В больших компаниях различных IT-систем существуют десятки, если не сотни. Лучший мировой опыт говорит, что все системы нужно разбить на классы (Mission Critical, Business Critical и т.п.), и выписать метрики для классов. В отдельных случаях могут быть индивидуальные исключения, но большая часть систем может быть покрыта универсальным SLA именно так.

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

Приложение. Прототип SLA

Ниже я собрал вместе всё вышеперечилсенное в виде шаблона, чтобы можно было скопировать структуру и доработать под свои условия. С чистого листа тяжелее начинать.

UPDATE: то, что не поместилось в основной статье:
Философия SLA: что такое эскалация и зачем она нужна
Философия SLA: про приоритеты запросов

В условиях всё нарастающей конкуренции работа над качеством услуг — неотъемлемая часть сервисного бизнеса.

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

SLA — что это такое?

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

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

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

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

Что такое OLA

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

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

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

Разница между SLA и OLA

Основное различие SLA и OLA в том, что первый документ описывает взаимодействие с внешним клиентом, а второй — работу подразделений внутри компании. И если SLA говорит на языке клиента и важных для него параметров сервиса («мы обеспечиваем доступность сервиса 99,8% времени»), то OLA погружается в технические детали и подробности взаимодействия отдельных подразделений и специалистов («диспетчер регистрирует заявку в течение 10 минут, инженер реагирует на нее в течение 2 часов, механик выезжает в течение 5 часов»).

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

SLA должен содержать описание предлагаемой услуги и определять границы ответственности.

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

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

Также в SLA должно быть прописано, при каких условиях услуга считается оказанной (когда ответственность исполнителя прекращается).

Параметры, от которых зависит SLA

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

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

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

В сервисном бизнесе самый распространенный параметр — время. Это может быть:

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

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

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

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

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

Договор SLA

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

Глазами клиента

В рамках SLA заказчик получает метрики предоставления услуги — четкое описание того, за что именно он платит.

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

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

Глазами сервисной компании

С точки зрения сервисного отдела или компании SLA — это набор целевых метрик, к которым стремятся исполнители. SLA на самом деле очень полезно, т.к. наводит порядок не только во взаимоотношениях с клиентом, но и (по цепочке) в бизнес-процессах самой сервисной компании.

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

Во взаимодействии с клиентом SLA помогает ограничить зону ответственности.

Как написать хороший SLA

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

Пройдемся по основным положениям, которые стоит добавить в SLA.

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

• Какую услугу предоставляет исполнитель — что, когда и где делает? К примеру, мы говорим об обслуживании сантехники в коммерческой недвижимости. Описываем, что услуга подразумевает ремонт и обслуживание сетей водопровода и водоотведения от вентиля жилищно-коммунальной службы на входе в здание. И указываем, что обслуживание осуществляется на территории заказчика в будние дни с 9 до 18 по Московскому времени.
• Какие предусмотрены ограничения услуги — географические, временные? Предположим, обслуживание и ремонт не производится в праздники и с 20:00 до 7:00 по Московскому времени.
• Есть ли какие-то приоритеты? К примеру, если речь про сантехнику и слегка подтекает кран, то это обращение обычного приоритета. А если прорвало стояк и заливает уже 3 этажа здания, то это явно аварийная ситуация. Если в рамках услуги такие ситуации должны обрабатываться по-разному, надо прописать, что такое обычное обращение, а какая ситуация будет рассматриваться, как аварийная.
• Какое подразделение (или несколько подразделений) исполнителя участвует, в чем его (их) роль?
• Каковы функции сотрудников подразделения? Если упоминаем диспетчеров, объясняем, что их функции — ответ на звонки, регистрация обращения и передача его профильному специалисту.

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

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

Метрики должны быть реалистичными. Если в примере с кассой установить в SLA скорость ремонта в 10 минут, скорее всего соглашение просто не будет работать. Более реалистичное, но короткое время, заставит привлекать опытных специалистов, которые в среднем работают с задачами быстрее. А это стоит денег. В этом смысле SLA — это поиск баланса между интересами клиента, который хочет «вчера», и исполнителя, который не может быстрее (или может, но в ущерб другим клиентам).

Метрик не нужно много. Большое количество метрик запутает исполнителя, он не сможет нормально расставить приоритеты в своей собственной работе, боясь выйти за рамки по какой-то из метрик.

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

Пример договора SLA

Ниже представлен пример договора SLA реальной IT-компании.

Предоставляемые услуги

В этом разделе мы описываем все работы, которые «IT-консалт» выполняет для Заказчика, и системы, которые находятся у нас на поддержке. По каждому виду работ определяется график и ограничения объема услуг, если они есть. Отдельно оговариваются те работы, которые не входят в нашу зону ответственности.

Исполнитель обязуется оказывать Заказчику услуги по сопровождению программного обеспечения 1С 8 ERP, установленного у Заказчика, на следующих инсталляциях:

• <Инсталляция 1>
• <Инсталляция 2>

Период оказания услуг — с «___» _______ ____ г. — «___» _______ ____ г.

Перечень услуг по сопровождению, время предоставления и ограничения по объему оказываемых услуг указан в таблице:

* Время часового пояса Москвы.

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

В перечень услуг, оказываемых Исполнителем, не входят следующие задачи:

• Поддержка оборудования и инфраструктуры системы (сервера, каналы связи, системное ПО, включая подсистему печати, сервер базы данных), лицензионные ключи на ПО
• Администрирование базы данных, в т.ч. обеспечение сохранности данных (резервное копирование).

Способы взаимодействия пользователей Заказчика и Исполнителя:

• E-mail
• Телефон
• Система Service Desk Исполнителя

Конкретные почтовые адреса, телефоны и учетные записи для Service Desk определяются в регламенте взаимодействия.

Ответственность Заказчика

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

Заказчик обязуется:

• Предоставить Исполнителю удаленный доступ к инсталляциям ПО для решения заявок;
• Предоставить Исполнителю копию рабочего ПО с тестовыми данными, для моделирования и решения проблем пользователей специалистами Исполнителя
• Предоставить Исполнителю серверные ресурсы, необходимые для разворачивания окружения для выполнения доработок.
• Обеспечить право Исполнителя на контроль кода рабочего приложения (отсутствие модификаций системы своими силами) с целью переноса ответственности за работоспособность системы на Исполнителя.
• Назначить и письменно сообщить Исполнителю Координатора, ответственного за взаимодействие в рамках услуг, описанных в настоящем Предложении:
  • Управление соглашением об уровне сервиса (инициация, согласование изменений) и вспомогательных регламентов со стороны Заказчика
  • Представление интересов бизнес-пользователей в согласовании изменений к Соглашению об уровне сервиса, а также вспомогательных регламентов
  • Разрешение конфликта интересов, если запрос одного бизнес-пользователя Заказчика конфликтует с запросом другого: по очередности и/или функционалу
  • Определение необходимости реализации, по каждой задаче на доработку системы
  • Приоритизация задач на доработку

Заказчик имеет право:

• Запрашивать у Исполнителя информация о статусе обработки заявок.
• Письменно информировать Исполнителя о недостатках в работе или нарушениях и требовать их исправления.
• Согласовывать с Исполнителем изменения в объемах выполняемых работ, заключать с Исполнителем Дополнительные соглашения об изменении объема услуг и работ для Заказчика, выполняемых Исполнителем.

Приоритеты и нормативное время решения заявок

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

Приоритет заявок определяется дежурным специалистом Исполнителя, исходя из бизнес-процесса, по которому поступила заявка от пользователя ПО, и характера заявки. Нормативное среднее время выполнения заявок и максимально допустимая доля заявок, время выполнения которых не уложилось в нормативное время, представлена в таблице:

По взаимному соглашению сторон приоритет заявки может быть изменен как в большую, так и в меньшую стороны.

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

• Уточнение у заказчика
• Согласование заказчиком
• Тестирование заказчиком
• Передано сторонней службе

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

Отчётность по услугам

Раздел определяет формат и частоту предоставления отчетов для Заказчика

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

Отчеты по количественным показателям (раздел III) содержат следующую информацию, в разбивке по приоритетам:

• Общее количество принятых заявок
• Среднее время выполнения заявок
• Доля просроченных заявок
• Полный перечень заявок, закрытых в течение периода
• Полный перечень заявок, оставшихся нерешенными на конец периода

Отчеты по количественным показателям предоставляются Исполнителем ежемесячно до 5 числа каждого месяца. Указанные отчеты оформляются как приложения к актам выполненных услуг, подписываются Исполнителем и Заказчиком.

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

• Удовлетворенность скоростью решения проблемы
• Удовлетворенность вежливостью специалистов поддержки
• Удовлетворенность фактом решения проблем

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

Отчеты по качественным показателям предоставляются Исполнителем дважды в год, до 20 июня и до 20 декабря.

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

Методика оценки качества сервиса

В этом разделе мы определяем то, как мы измеряем качество сервиса. Мы приводим перечень метрик качества, как количественных, так и качественных, и определяем вес (важность) каждой метрики, исходя из бизнеса клиента

Исполнитель обязуется ежемесячно рассчитывать итоговый показатель качества сервиса (QoS), на основании следующего расчета:

* По данным последнего проведенного опроса пользователей

Итоговый показатель качества (QoS) рассчитывается как сумма весов по тем метрикам, которые были выполнены в периоде.

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

Стоимость услуг, штрафные санкции и условия оплаты

Основной пункт в этом разделе — это расчет штрафных санкций, которые «IT-консалт» применяет к месячному акту в том случае, если нарушаем метрики качества.

Стоимость услуг Исполнителя составляет ________ (___________) рублей в месяц, без учета НДС.

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

Штрафные санкции могут быть начислены начиная с 3-го месяца оказания услуг. Первые два месяца являются ознакомительным периодом, в котором Исполнитель нарабатывает компетенцию в приложении Заказчика.

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

Стоимость дополнительного сервиса, оказываемого по требованию Заказчика:

• При превышении указанного в разделе I объема заявок, стоимость каждой заявки сверх указанного объема, составит ______ (_______) руб, без учета НДС, за одну заявку.
• При необходимости выполнения доработок сверх указанного в разделе I объема, стоимость одного человеко-часа будет составлять ______ (_______) руб, без учета НДС. Подписание Сторонами Акта приема-передачи услуг по результатам выполненных доработок осуществляется по факту завершения пользовательского тестирования.
• Стоимость работы поддержки в выходные и праздничные дни — ______ (_______) руб./день, без учета НДС, вне зависимости от количества специалистов поддержки. Основанием для начисления стоимости является запрос на услуги поддержки в выходной день, направленный Исполнителю по электронной почте Координатором.

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

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

Источник: Компания «ФТО».

Как работать по SLA?

Схема работы по готовому соглашению предельно понятна:

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

Отметим, что соблюдать SLA проще, если процессы в сервисной компании отлажены. Помогают этому различные инструменты автоматизации, в частности, Help Desk.

Для создания хорошего SLA требуется:

• Описание услуг.

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

• Описание неполадок.

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

• Время решения проблем.

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

Расскажите, в какие дни и в какое время суток обрабатываются заявки по разным категориям услуг.

• Приоритетность.

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

• Ответственность сторон.

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

• Исполнители и их функции.

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

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

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

Что представляет из себя SLA?

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

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

Например, соглашение об уровне сервиса могут применять в сфере обслуживания оборудования.

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

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

Например, у клиента перестало работать оборудование. Он оставит обращение и будет ждать ответа. Время реакции может составлять, например, 1 час, а время решения — до 1 рабочего дня. Если вы успеваете в эти сроки, то вы выполнили обслуживание клиента в соответствии с SLA.

Для того, чтобы выполнять условия соглашения компании составляют и другой документ — OLA. О нём мы поговорим дальше.

Отличие SLA и OLA

Эти два документа, хоть и похожи, но различаются по своему назначению.

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

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

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

Соблюдение требований, указанных в обоих документах, можно автоматизировать с помощью программ для организации технической поддержки — сервис-десков. Одной из таких программ является Admin24 – Service Desk, в которой есть возможность настройки времени реагирования на заявку и времени её выполнения.

Как составить соглашение

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

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

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

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

Чек-лист

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

Можно ли автоматизировать соблюдение SLA?

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

Для этого компании используют системы Service Desk — программы для автоматизации поддержки.

Российская система для автоматизации обращений клиентов и сотрудников Admin24 – Service Desk позволяет настраивать параметры SLA, например, время реагирования на заявку и время её выполнения. Для разных компаний, форм и услуг можно устанавливать разные параметры и назначать разных руководителей.

Настраивайте SLA, работайте с заявками и автоматизируйте поддержку вместе.

***

Admin24 – Service Desk — это российская система для автоматизации обработки обращений клиентов и сотрудников. Переходите по ссылке и тестируйте возможности Админ24 для внутренней поддержки бесплатно 30 дней!

Систему можно интегрировать с Битрикс24, Telegram, Вконтакте и Одноклассниками.

***

Подписывайтесь на Admin24 – Service Desk в TenChat. Там ещё больше интересного.

Узнать больше о настройках Admin24 – Service Desk на YouTube.

Что такое SLA, для чего оно нужно IT-компаниям и как его составить, чтобы наладить эффективное сотрудничество с заказчиками.

Что это такое – SLA

SLA (англ. Service Level Agreement – соглашение об уровне сервиса) – это соглашение между заказчиком и исполнителем о том, какие, когда и как будут предоставляться услуги. Также в него входят права и обязанности сторон. Используется SLA в IT и сфере телекоммуникаций.

Этот термин относится к методологии ITIL (англ. IT Infrastructure Library – библиотека инфраструктуры информационных технологий), в которой описываются лучшие способы организации работы компаний, предоставляющих IT-услуги.

Для чего нужно SLA

Простыми словами, SLA – это договор, в котором подробно описаны предоставляемые услуги, их качество, время реагирования на заявку и ее исполнение.

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

Например, главбух клиента может быть недоволен, что админ со стороны провайдера поднимает какой-то там сервер (делов-то на 5 минут, а он уже 2 часа возится), вместо того чтобы заправить картриджи в бухгалтерии.

И чтобы избежать таких моментов и сохранить хорошие отношения, аутсорсинговая компания может составить SLA, в котором:

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

И теперь клиенты будут знать, что если разом перестали работать 20 тонких клиентов из 30, то сотрудник сможет заняться этим через 15–30 минут, а на устранение уйдет от 1 до 5 часов. А если проблема с принтером, то отклик будет только через час, хотя решение проблемы займет всего 10 минут.

Как составить SLA

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

1. Определение сторон предоставляемого сервиса и сроков действия договора.
2. Дни и часы оказания услуг (включая тестирование, поддержку и модернизацию).
3. Количество пользователей и оборудования, а также их территориальное размещение.
4. Описание процедуры составления отчетов о неполадках.
5. Описание процедуры заполнения заявок на обслуживание.
6. Определение уровней качества предоставления услуги.
7. Описание платежей.
8. Ответственность заказчика.
9. Способы решения разногласий.
10. Возможные действия по улучшению договора.

Все эти пункты должны быть прописаны очень подробно. Так, например, описывая уровень качества, нужно учесть такие параметры, как:

• средняя доступность сервера (если исполнитель оказывает услуги хостинга);
• минимальная доступность;
• среднее время отклика исполнителя на обращение;
• максимальное время отклика;
• средняя пропускная способность соединения (если исполнитель является интернет-провайдером).

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

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

Наиболее полную информацию о SLA можно встретить в описаниях стандартов ITIL и COBIT (от англ. Control Objectives for Information and Related Technologies – «Задачи управления для информационных и смежных технологий»).

Не отпугивает ли это клиентов

Основное отличие SLA от обычного договора − в том, что уровень качества прописан достаточно подробно. Для сравнения, в обычном договоре может быть написано следующее:

Исполнитель обязуется устранить неисправность после обращения заказчика.

В SLA же будет написано:

Исполнитель обязуется приступить к устранению неисправности в течение 30–60 минут в будний день с 9 до 18 часов и исправить ее в течение 5–10 часов.

Это немного не совпадает с желаниями заказчика – он хочет, чтобы провайдер был готов разобраться с локальным концом света в режиме 24/7. Поэтому некоторые потенциальные клиенты могут отказаться от сотрудничества, прочитав SLA.

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

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

В этом отношении у SLA есть явные преимущества:

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

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

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

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

Рассказываем об IT-бизнесе, технологиях и цифровой трансформации

Подпишитесь в соцсетях или по email

Помните, когда вы подняли запрос на обслуживание и получили отложенное решение?

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

Именно здесь соглашение об уровне обслуживания (SLA) защищает организации от таких нарушений.

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

Каковы разумные сроки?

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

Определение – Соглашения об уровне обслуживания (SLA)

Соглашение об уровне обслуживания (SLA) — это договор между компанией и ее клиентами, который определяет уровень обслуживания, которое будет предоставлять компания. Он также определяет, что происходит, когда компания не соответствует этим стандартам.

Сторонами, участвующими в процессе, могут быть отдельные организации или группы. Существует три основных типа SLA:

• SLA на основе клиента,
• SLA на основе услуг,
• И многоуровневое SLA.

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

Почему управление SLA важно для организации?

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

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

1. Это помогает улучшить обслуживание клиентов.

Для любой организации основной задачей является обеспечение невероятного качества обслуживания клиентов за счет предоставления качественных услуг и сокращения среднего времени решения (MTTR) до 80%. SLA помогают улучшить общее управление услугами, в конечном итоге обеспечивая исключительное обслуживание клиентов.

2. Улучшение коммуникации и подотчетности

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

• Клиенты (сотрудники) могут легко ссылаться на установленные приоритеты в документе SLA и максимальное время, отведенное поставщику услуг.
• Организации могут обращаться к периодическим отчетам о производительности, чтобы понять результаты поддержки.

3. Он определяет процедуры и стандарты для заказчика.

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

4. Это дает вам душевное спокойствие.

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

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

Базовая структура шаблона соглашения об уровне обслуживания (SLA)

В SLA включено несколько пунктов. Вот основная структура.

1. Соглашение об уровне обслуживания

Когда вы создаете свой шаблон SLA, первое, что вам нужно включить, это:

• Детали версии
• Вся история документа
• Утверждение документов

2. Обзор соглашения

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

3. Сервисное соглашение

Это наиболее расширенный и важный компонент любого шаблона SLA, который включает в себя следующее:

• KPI и показатели
• Уровни обслуживания, ранжирование и приоритет
• Ответ службы
• Исключения и ограничения
• Цели и задачи
• Ответы и обязанности
• Service Management

4. Управление услугами

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

5. Заинтересованные стороны

Раздел «Заинтересованные стороны» включает все стороны, участвующие в соглашении.

6. Периодический обзор

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

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

Некоторые общие показатели SLA

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

• Уровень дефектности
• Скорость отказа
• Среднее время ответа
• Разрешение первого звонка
• Время оборота
• Тем временем, чтобы восстановить

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

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

Оптимизируйте управление SLA с помощью ориентированного на результат инструмента ITSM от Motadata

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

Вот некоторые ориентированные на результат функции SLA, которые содержит инструмент ITSM Motadata:

1. Максимальное время отклика – При создании SLA в инструменте Motadata ITSM вы можете зафиксировать максимальное время отклика, чтобы технический специалист мог ответить на конкретный тикет.

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

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

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

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