Sla что это такое простыми словами в бизнесе

Что такое 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

Содержание:

1. 
   Что должно быть в SLA?

2. 
   SLA: с чего начать

Service Level Agreement или SLA (соглашение об уровне сервиса) — три слова, определяющие подходы компании к организации ИТ-процессов. Согласно ITIL (IT Infrastructure Library) SLA — это мини-договор, устанавливающий параметры качества предоставляемых бизнесу ИТ-услуг.
В SLA описываются условия предоставления услуг (сервисов), устанавливается перечень таких услуг, а также правила, по которым заказчик будет пользоваться этими сервисами. В то же время SLA — один из основных механизмов, позволяющих управлять качеством ИТ-услуг и управлять ожиданиями пользователей.

Что должно быть в SLA?

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

Говоря иными словами, для ИТ-подразделения SLA — это набор параметров ключевых ИТ-процессов, а соблюдение SLA — основной ключевой показатель эффективности (KPI) ИТ-отдела.

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

SLA: с чего начать

Чаще всего к разработке SLA приходят в контексте внедрения Service Desk-системы. Начиная внедрять у себя управление уровнем качества обслуживания пользователей, не стоит пытаться объять необъятное, начните двигаться вперед небольшими шагами.

1. Группируем пользователей, начинаем с 2-3 групп.
   Начните с 2-3 групп, например, VIP-пользователи и Обычные пользователи
2. Определяем критические ИТ сервисы, не больше 4
   Определите несколько критических сервисов, управление качеством которых не требует отлагательств. Например, в торговой организации одним из таких сервисов станет подключение к crm-системе менеджеров по продажам. В любом случае, это будет какая-то часть вашего каталога сервисов, предоставляемых ИТ-службой
3. Устанавливаем реальные нормы качества для SLA, с учетом наших возможностей и целевые показатели
   Определите параметры качества предоставления сервисов и установите для них реальные нормативы. Эти параметры должны соотноситься с бизнес-целями организации и быть отражением потребностей бизнес-пользователей, в том числе в способах оказания им ИТ-услуг. Такими параметрами могут быть:
   1. время устранения инцидентов,
   2. время, в течение которого сервис должен быть восстановлен, и т.п.Важно знать, от каких процессов зависит качество этих ИТ-сервисов. Эти процессы будут служить ограничивающим фактором при установлении сроков в SLA (правда, оптимизация этих процессов — уже совсем другая история). Например, при создании нового рабочего места производится закупка нового оборудования, поэтому сроки подготовки рабочего места не могут быть меньше, чем сроки закупки.И, как бы всем участникам процесса не хотелось, чтобы все заявки по какому-то сервису закрывались за 5 минут, если традиционно они закрываются по 10 дней — значит от 10 дней и надо начинать плясать.
4. Фиксируем SLA Зафиксируйте SLA для ваших групп пользователей с выбранными нормами качества по выбранным критическим сервисам.
5. Информируем всех без исключения пользователей
6. Постоянно измеряем соблюдение SLA по выбранным параметрам качества вы должны с открытыми глазами смотреть на ситуацию, сколько SLA за период были выполнены, какие нормативы были соблюдены, какие систематически нарушаются. Только такие данные позволят вам в дальнейшем принимать взвешенные управленческие решения, а не руководствоваться ощущениями.
7. Постоянно анализируем и оптимизируем процессы до достижения целевых показателей

Ищите способы оптимизации процессов, чтобы постепенно приближать, например, сроки в SLA к тем, которые нужны бизнесу. Этот процесс называется — Service Level Management, SLM.

Метки поста: PM

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

В отличие от обычных договоров оказания услуг, Service Level Agreement предлагает очень подробное описание качества услуг, режима работы, времени реагирования на обращение и других параметров.

Соглашение об уровне сервиса обычно обладает следующими характеристиками:

• Максимально возможная прозрачность всех процессов и взаимодействий между поставщиком услуг и клиентом. При составлении договора стараются избегать размытых формулировок, которые можно трактовать двояко в ту или иную сторону. 
• Понятные всем участникам соглашения права и обязанности. Например, провайдер обязуется обеспечить доступность сервисов в 99,9% времени и оплатить компенсацию при зафиксированном меньшем значении, а клиент имеет право запросить эту компенсацию.
• Управление ожиданиями. Например, клиент ожидает, что поддержка будет круглосуточной и очень быстрой даже по самым незначительным вопросам, а провайдер не может предоставить такую услугу. В таком случае клиенты стоит либо понизить свои ожидания, либо заключить договор с другим провайдером. Может быть и третий вариант — провайдер повысит уровень сервиса, если это принесет пользу его бизнес-процессам.

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

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

Что обычно указывают в SLA

Выше мы привели пример SLA от Amazon Web Services. Это не стандарт, а лишь один из вариантов, который учитывает специфику конкретного сервиса.

В SLA для IT часто расписывают следующие пункты:

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

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

При описании качества сервиса также раскрываются его параметры. Обычно это:

• Доступность самого сервиса.
• Время реакции на возникшую проблему.
• Время устранения неисправностей.

В соглашение может быть также указана метрика часов работы. 

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

Ключевые параметры SLA

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

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

Допустим, компания делит всех клиентов на несколько групп. Первой группе гарантируют круглосуточную поддержку по телефону и в чате. Второй — поддержку по телефону и в чате, но только по будням. Третьей — поддержку только в чате и только по будням.

Метрики нужны для того, чтобы все участники соглашения понимали, какие услуги, когда и в каком объеме они получат. Отсюда следуют несколько характеристик:

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

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

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

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

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

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

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

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

Время отклика на вызов клиента и время решения проблемы в совокупности составляют время простоя. 

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

Доступность услуги

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

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

Например, на cloud.timeweb.com доступность по SLA — 99,99%. Соглашение гарантирует, что простой сервисов не превысит 52 минут в год. 

Провайдеры могут обещать и пять девяток — 99,999% или не более 15 минут простоя сервисов в год. Но это не всегда лучшее решение. Есть как минимум две вещи, которые стоит иметь в виду:

• Чем выше показатель SLA, тем дороже обслуживание.
• Далеко не каждому клиенту нужен такой уровень SLA. В подавляющем большинстве случаев достаточно базовых 99,982% или немного выше.

Смотреть стоит не только на количество девяток, но и на время, которое провайдер указывает для контроля. По умолчанию в договор SLA вписывают показатели за год. Например, вам обещают, что сервисы будут доступны 99,95% времени. Простой — не более 4,5 часов в год.

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

Еще один важный момент — совокупная доступность. Она равна наименьшему показателю.

Плюсы SLA

Подписание и соблюдение SLA выгодно обеим сторонам. 

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

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

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

SLA и SLO: в чем разница

SLA также можно рассматривать в качестве индикатора удовлетворенности пользователей. Высшее значение — 100%, низшее — 0%. 

Добиться абсолютной удовлетворенности (100%) невозможно — так же, как нельзя гарантировать, что по SLA server всегда будет доступен. Поэтому при выборе конкретных метрик рекомендуют смотреть на продукт реалистично и выбирать посильные значения. 

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

Чтобы отслеживать уровень сервиса внутри компании, придумали еще одну систему — SLO. Это те значения метрик, которые поставщик услуг хотел бы достичь (objectives). 

Берем тот же пример с технической поддержкой. Допустим, текущие возможности — обработка 50 обращений в течение рабочего дня, график — с 9:00 до 18:00 пять дней в неделю. Эти метрики компания фиксирует в SLA и показывает клиентам. 

Параллельно составляется еще один документ — SLO. Это основа, на которой выстраивается управление уровнем услуг. В SLO учитываются текущие метрики, закрепленные в SLA, но дополнительно есть цель: например, увеличить количество обработанных обращений в течение рабочего дня до 75 или сделать поддержку круглосуточной. От этого зависит будущий IT-service level. 

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

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

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

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

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

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

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

Чек-лист: на что обратить внимание при подготовке SLA

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

• Пользователи. В больших системах рекомендуется разделять пользователей на группы и работать с ними отдельно. Это помогает эффективнее распределить ресурсы и не разрываться между запросами разных групп клиентов.
• Сервисы. Здесь важна критичность сервиса для конкретной группы клиентов. Например, вы предлагаете CRM торговым компаниям. Если они не смогут ей пользоваться, то понесут убытки и придут с претензиями. Поэтому у такого сервиса самый высокий уровень критичности. Условная замена принтера или создание новой учетной записи для сотрудника на этом фоне может подождать до завтра.
• Параметры качества сервисов. Они должны соотноситься с бизнес-целями компании и потребностями клиентов. Стандартный пример — время и порядок устранения инцидентов. Например, компания может гарантировать круглосуточную поддержку или решать проблемы только по будням с 9:00 до 18:00.

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

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

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