Образец SLA для клиентов в 1С

Что такое SLA: определение и значение

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

Преимущества внедрения SLA для компаний и клиентов

1. Детальное и конкретное описание параметров качества каждой из предоставляемых услуг.
2. Наличие измеримых показателей, сроков реакции и зон ответственности сторон.
3. Понятный язык с четкими, однозначными формулировками, без юридических терминов.
4. Концентрация на количественных и качественных показателях доступности сервиса и скорости реакции на инциденты.
5. Указание способов контроля уровня сервиса.

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

30 часов тест‑драйва Сопровождения 1C
бесплатно

• Тестовый период для вашего решения 1С на 2 недели, на любые виды работы в рамках услуги Сопровождения 1С
• Реализация доработок — до 5 часов на одну задачу

Заказать тест-драйв

Виды SLA

1. Стандартизированное SLA — универсальное соглашение для всех клиентов. Применяется для массовых услуг, в которых не подразумевается кастомизированной настройки.
2. Индивидуальное SLA — соглашение, адаптированное под конкретного клиента, учитывающее его потребности и бизнес‑процессы. Предусматривает гибкие настройки и персонализацию сервиса.
3. Многоуровневое SLA — соглашение, заключаемое для поддержки глобальных проектов или в корпорациях со сложной оргструктурой. Может сочетать несколько функциональных подходов к техподдержке. Условия разделяют на уровни, например:
   • корпоративный уровень — общие обязательства перед заказчиком;
   • сервисный уровень — параметры работы конкретного сервиса;
   • пользовательский — услуги для сотрудников клиента.
4. Внутреннее SLA — соглашение в рамках компании, по которому одно подразделение является поставщиком услуг, а другое — заказчиком. Оно обеспечивает синхронизацию работы команд и слаженность процессов.
5. Партнерское SLA — соглашение, заключаемое компаниями, совместно предоставляющими услуги клиенту. Такой документ помогает разграничить зоны ответственности.

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

Структура SLA: ключевые разделы соглашения

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

Подготовка к составлению SLA

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

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

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

Типовая структура соглашения об уровне обслуживания

Структура и фокус SLA зависят от специфики услуг, масштаба проекта и требований клиента.

Можно выделить основные, универсальные разделы SLA:

1. Общая информация, стороны и срок действия соглашения.
2. Описание услуг:
   • детальный перечень предоставляемых услуг, распределенных по категориям;
   • описание оборудования и программного обеспечения, задействованных в процессах;
   • временные и территориальные рамки предоставления услуг;
   • круг пользователей услуг;
   • стоимость услуг.
3. Параметры качества:
   • конкретные и измеримые целевые значения для каждой услуги;
   • максимальный период простоя;
   • формулы расчета метрик и KPI;
   • условия, при которых услуга считается оказанной.
4. Организация взаимодействия между сторонами.
5. Отчетность и мониторинг.
6. Ответственность сторон.
7. Нарушения и компенсации, порядок работы с претензиями.

Если SLA содержит много технических и прочих специфических терминов, необходимо составить к нему глоссарий. Целесообразно в качестве исключений указать форс-мажоры, при которых условия SLA перестанут действовать. Рекомендуем предусмотреть срок пересмотра условий SLA — например, раз в 3 месяца, когда станет понятно, насколько выполнимы метрики в реальных условиях.

Уровни приоритета SLA

В SLA часто указывают различную скорость реагирования и время обработки для заявок с разным приоритетом. Заявки можно ранжировать по степени их влияния на работоспособность ИТ‑инфраструктуры или по категориям клиентов.

Уровни приоритета классифицируются следующим образом:

1. Критический приоритет, P1 — ситуация, требующая немедленного реагирования и максимально быстрой работы для восстановления работоспособности сервиса.
2. Высокий приоритет, P2 — серьезная и срочная проблема, не требующая перехода в авральный режим.
3. Нормальный приоритет, P3 — существенная проблема, с решением которой можно повременить, поскольку имеется обходной путь.
4. Низкий приоритет, P4 — проблема, не оказывающая ощутимого влияния на работу, но требующая решения в перспективе.

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

Пример положений SLA

В качестве примера приведем несколько положений типового SLA для технической поддержки:

Рекомендации по разработке SLA: как составить соглашение

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

1. Во вводной части обозначьте всех участников процесса — от ключевых пользователей до специалистов технической поддержки всех уровней.
2. Четко определите границы SLA — зафиксируйте, какие услуги входят в соглашение, в каком формате они оказываются, какие регионы охватывают и т.д.
3. Установите для каждой услуги сроки реагирования и решения проблемы.
4. Пропишите доступность услуг — то, в какие дни и часы они предоставляются, возможны ли технические перерывы, как работает поддержка в праздники.
5. Предусмотрите приоритезацию обращений по уровням и четко укажите критерии их ранжирования.
6. Определите значения метрик на основании отраслевых стандартов, бенчмарок, исторических данных в аналогичных проектах.
7. Для тех услуг, которые выходят за рамки SLA (например, если в SLA входит 40 часов на доработки, а понадобилось 55), составьте прейскурант и пропишите условия их предоставления.
8. Сохраняйте историю версий SLA, чтобы всегда можно было проанализировать эффект от внесения изменений.
9. Проанализируйте метрики на предмет их непротиворечивости друг другу.
10. Опишите алгоритмы действий в случае нештатных ситуаций и форс-мажоров.
11. Зафиксируйте максимальное количество единовременно решаемых заявок каждого типа. Например, когда согласно SLA поставщик обязан принять в работу до 40 заявок в месяц, в день в неавральном режиме получится закрывать до 2-4 заявок.

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

Внедрение и контроль исполнения SLA

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

Для полноценного контроля нужно на ежедневной или еженедельной основе анализировать отчеты:

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

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

Ошибки при внедрении SLA и как их избежать

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

Заключение

Согласно статистике компании «Первый Бит», экономия затрат заказчика на поддержку при заключении SLA достигает 70%. Во-первых, не нужно содержать собственный штат специалистов поддержки. Во-вторых, отсутствуют простои в работе и все задачи решаются в срок. При этом вся финансовая ответственность за качество поддержки и работоспособность информационных систем ложится на поставщика услуг. Поддержку осуществляет группа специалистов, находящаяся в контексте бизнес‑процессов заказчика и координируемая закрепленным менеджером. Отчеты с возможностью детализации по каждой заявке дают возможность оценить качество выполнения услуг и оптимизировать их.