Tla sla что это

Обновлено: 30.06.2024

Восприятие бренда может измениться от одного неудачного опыта.

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

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

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

Соглашение об уровне обслуживания (SLA) - мощный инструмент для ИТ-руководителей, позволяющий своевременно решать возникающие проблемы; таким образом, гарантируя своевременное оказание услуг.

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

Что такое SLA?
Почему важно иметь SLA?
3 распространенные типы SLA
Что такое управление уровнем обслуживания?
Каковы основные компоненты хорошего SLA?
Как установить показатели SLA?
Какие общие показатели SLA?

Что такое SLA?

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

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

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

Например; Считайте себя новым сотрудником в вашей организации, и ваш HR инициирует заявку, чтобы ИТ-команда могла вас присоединить. SLA в этом случае будет определять следующее:

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

Мотаданные СервисОпс ITSM позволяет легко создавать соглашения об уровне обслуживания с условиями, критериями времени и правилами эскалации.

Почему важно иметь SLA?

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

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

3 Распространенные типы SLA

Есть три типа SLA, используемых в бизнесе, они:

SLA на основе клиентаЭто соглашение, заключенное с одним клиентом, содержащее все необходимые услуги, необходимые клиенту. Как правило, в таких соглашениях используется единый договор, который удобен для продавца из-за его простоты. Например; поставщик услуг VoIP может объединить все связанные голосовые услуги в один контракт.
Сервисный SLA: Это контракт, определяющий одну услугу для всех клиентов. SLA зависит от неизменных стандартов, что делает его простым и понятным для поставщиков. Например, соглашение об уровне обслуживания, регулирующее порядок разрешения обращений службы поддержки, будет действовать для всех клиентов, согласившихся на получение его услуг.
Многоуровневый SLAВ таком соглашении конечный пользователь имеет возможность настройки в соответствии со своими потребностями; Пользователь может добавить несколько условий для создания подходящего сервиса.

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

Корпоративный уровень: это исчерпывающее описание соглашения, охватывающее общие вопросы УУЗР, подходящее для всех в организации.
Уровень клиента: Охват вопросов УУЗР, относящихся к определенной группе клиентов.
Уровень обслуживания: охватывает вопросы SLM для конкретной услуги, относящейся к определенной группе клиентов.

Что такое управление уровнем обслуживания (SLM)?

Управление уровнем обслуживания (SLM) - это практика управления соглашениями об уровне обслуживания путем определения, документирования, оценки и оценки уровня предлагаемых услуг. При наличии хороших практик УУЗР организация может:

Каковы основные компоненты хорошего SLA?

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

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

Как установить показатели SLA?

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

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

Какие общие показатели SLA?

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

Вот некоторые общие метрики, используемые в отношении службы поддержки:

Уровень дефектности: процент ошибок, допущенных при предоставлении решения.
Уровень отказов: процент заявок, на которые не ответили в течение времени ответа. Загрузите Motadata ServiceOps ITSM и посмотрите, насколько просто установить время ответа SLA.
Среднее время ответа: среднее время, необходимое технику для ответа на заявку.
Разрешение первого вызова: процент заявок, разрешенных без необходимости инициировать второй контакт запрашивающей стороне.
Время выполнения: среднее время, необходимое для выполнения определенной задачи.
Между тем, чтобы восстановить: среднее время, необходимое для устранения определенного вида сбоя в обслуживании.

Мотаданные СервисОпс ITSM позволяет пользователям фиксировать все ключевые показатели SLA через модуль отчетности.

Заключение

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

Графики обслуживания и время работы технической поддержки

График обслуживания заявок определяет рабочие часы, в течение которых «считается» время решения заявки. Например, если норматив на решение 8 часов, а уровень обслуживания клиента предусматривает оказание услуг только по рабочим дням с 9 до 18 часов, то отправленная в 17:00 пятницы заявка по нормативу должна быть решена не в час ночи субботы, а в 16:00 следующего понедельника.

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

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

Справочник графиков обслуживания Вы определяете в разделе «Настройки \ Заявки \ Нормативы обработки заявок (SLA)» на вкладке «Графики обслуживания заявок». Для добавления нового графика нажмите на кнопку «+ Добавить график обслуживания» и следуйте указанием интуитивно понятного интерфейса :)

Хватит думать, что SLA вас спасет. Оно нужно, чтобы успокоить и создать ложное чувство безопасности

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

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

Что чаще всего пишут в публичной версии SLA хостеры, которую показывают публике? Ну, первой строкой идет такой термин, как «надежность» хостера — это обычно цифры от 98 до 99,999%. По сути, эти цифры — лишь красивая выдумка маркетологов. Когда-то, когда хостинг был молодым и дорогим, а облака только снились специалистам (как и широкополосный доступ для всех и каждого), показатель аптайма хостинга был крайне и крайне важен. Сейчас же, когда все поставщики используют плюс-минус одно и тоже оборудование, сидят на один и тех же магистральных сетях и предлагают одни и те же пакеты услуг, показатель аптайма абсолютно непоказателен.

Бывает ли вообще «правильный» SLA

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

Что должно быть в хорошем SLA? Если дать TLDR, то хороший SLA — это регулирующий отношения двух субъектов документ, который дает одной из сторон (заказчику) максимум контроля над процессом. То есть, как это работает в реальном мире: есть документ, который описывает глобальные процессы взаимодействия и регулирует взаимоотношения сторон. Он устанавливает границы, правила и сам по себе становится рычагом воздействия, которым могут пользоваться обе стороны в полной мере. Так, благодаря правильному SLA заказчик просто может заставить исполнителя работать так, как договаривались, а исполнителю — помогает отбиваться от необоснованных договором «хотелок» слишком уж активного клиента. Выглядит так: «У нас в SLA написано так и так, идите отсюда, мы все делаем как оговорено».

То есть «правильный SLA» = «адекватный договор на оказание услуг» и дает контроль над ситуацией. А возможно это только при работе «на равных».

То, что пишут на сайте и то, что ждет в реальности — разные вещи

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

Если взять популярных отечественных хостеров, то одно предложение краше другого: поддержка 25/8, аптайм серверов 99,9999999% времени, куча своих дата-центров минимум по России. Запомните, пожалуйста, момент про дата-центры, мы к нему вернемся чуть позже. А пока поговорим про идеальную статистику отказоустойчивости и с чем сталкивается человек, когда его сервер все же попадает в «0,0000001% падений».

При показателях от 98% и выше, любое падение — событие на грани статистической погрешности. Рабочее оборудование и коннект либо есть, либо их нет. Вы можете годами пользоваться хостером с показателем «надежности» в 50% (согласно его же SLA) без единой проблемы или «падать» раз в месяц на пару дней у ребят, где заявлено 99,99%.

Когда момент падения все же настает (а падают, напоминаем, когда-нибудь все), то тут клиент сталкивается с внутренней корпоративной машиной под названием «поддержка», а на свет достается договор на оказание услуг и SLA. Что это значит:

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

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

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

«Множество дата-центров по всему миру» — повод для беспокойства

Ситуацию с большим количеством дата-центров у поставщика услуг мы вынесли в отдельную категорию, потому что кроме очевидных вышеописанных проблем с коммуникацией всплывают проблемы и неочевидные. Например, ваш поставщик услуг не имеет доступа к «своим» дата-центрам.

В нашей прошлой статье мы писали о видах партнерских программ и упомянули модель «White Label», суть которой заключается в перепродаже чужих мощностей под своей вывеской. Подавляющее большинство современных хостеров, которые заявляют о наличии «своих дата-центров» во множестве регионов, являются перекупщиками по модели White Label. То есть, физически они не имеют никакого отношения к условному дата-центру в Швейцарии, Германии или Нидерландах.

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

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

Почему мы не рассматриваем варианты, когда множество ДЦ на самом деле может принадлежать одной компании? Ну, таких компаний очень и очень немного. Один, два, три небольших дата-центра или один крупный — это реально. Но десяток ДЦ, половина из которых в РФ, а вторая на территории Европы — практически невозможно. А это значит, что компаний-перекупщиков намного больше, чем можно себе представить. Вот простой пример:

Оцените количество дата-центров сервиса Google Cloud. В Европе их всего шесть. В Лондоне, Амстердаме, Брюсселе, Хельсинки, Франкфурте и Цюрихе. То есть на всех основных магистральных точках. Потому что дата-центр — это дорого, сложно и очень большой проект. А теперь вспомните хостинговые компании откуда-то из Москвы с «десятком дата-центров по всей России и Европе».

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

Это еще раз напоминает нам, что SLA бесполезен, если вы не имеете понятия о структуре организации и мощностей поставщика.

Что в итоге

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

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

В первую очередь нужно выявить, является ли продавец услуг непосредственным владельцем мощностей/дата-центра. Очень многие перекупщики по модели White Label изо всех сил маскируют свой статус и в этом случае надо смотреть на какие-то косвенные признаки. Например, если «их европейские ДЦ» имеют какие-то специфические названия и логотипы, отличающиеся от названия компании-поставщика. Или если где-то мелькает слово «партнеры». Партнеры = White Label в 95% случаев.

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

Со многими дата-центрами можно договориться о личном визите в офис и мини-экскурсии в сам ДЦ. Там можно оценить степень порядка, возможно, удастся пообщаться с кем-нибудь из инженеров. Понятно, что никто не будет устраивать вам экскурс на производство, если вам нужен один сервер за 300 RUB/месяц, но если вам требуются серьезные мощности, то отдел продаж вполне может пойти вам на встречу. Мы, например, такие экскурсии проводим.

В любом случае следует руководствоваться здравым смыслом и потребностями бизнеса. Например, при необходимости распределенной инфраструктуры (часть серверов в РФ, вторая — в ЕС), проще и выгоднее будет воспользоваться услугами хостеров, имеющих партнерские отношения с европейскими ДЦ по модели White Label. Если же вся ваша инфраструктура будет сконцентрирована в одной точке, то есть в одном дата-центре, то стоит уделить вопросу поиска поставщика некоторое время.

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

Время реакции. Контроль времени реакции согласно SLA

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

Контролируйте SLA по всем договорам в Okdesk бесплатно Даём бесплатный доступ на 14 дней с полным функционалом!

Контроль SLA
Учёт потраченного на работу времени
Автоматический учёт и распределение заявок между специалистами
Интеграции с e-mail, Telegram, 30+ АТС и другими сервисами
Учёт затрат, оборудования и объектов обслуживания

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

Плановое время реакции и фактическое время реакции рассчитываются и фиксируются в Okdesk автоматически, так же как и плановое/фактическое время решения.

Краткая предыстория возможностей по работе с SLA в Okdesk

С первого дня своего существования Okdesk позволял учитывать SLA для контроля времени решения заявок и графиков обслуживания в привязке к конкретным клиентам. Кроме того, при использовании автоматических правил (доступны на тарифах «Эксперт» и выше) можно было задавать алгоритм автоматического расчета планового времени решения заявок в зависимости от значения других параметров конкретной заявки. Но этого было мало, да и автоматические правила были доступны не для всех клиентов Okdesk.

Okdesk, пожалуй, самый активно развивающийся Help Desk на рынке. А потому мы каждый день улучшаем возможности его использования для Вас, предоставляя новые настраиваемые механизмы!

Что такое SLA?

Соглашение об уровне обслуживания (SLA) - это соглашение или контракт между поставщиком услуг и его клиентом о предоставлении услуг, которые соответствуют ожиданиям клиента.

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

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

Соглашения об уровне обслуживания технологических компаний могут включать в себя обязательство по обеспечению бесперебойной работы сети на уровне 99.99%. Если этого не добиться, заказчик имеет право сократить свой платеж на определенный процент в зависимости от масштаба отключения. Если вы хотите узнать больше о том, как устанавливать, измерять и составлять отчеты об уровне обслуживания, посетите наш блог на 5 Практические советы по настройке, измерению и составлению отчетов об SLA.

SLA. Как контролировать SLA, время решения и время реакции по заявкам клиентов?

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

Рады представить новый модуль, который мы разработали согласно Вашим требованиям и всем передовым мировым практикам сервисного обслуживания! Какие возможности предоставляет новый модуль «учета SLA» в Okdesk? Как это работает и чем он Вам поможет?

Важность SLA

SLA для конечный пользователь «s спокойствие духа. У них будет an SLA, чтобы они могли см. это всякий раз, когда они требовать в держать их подотчетность поставщика. It также перечисляет детали о том, какой тип обслуживание, которое они получат. In дома их потребности не удовлетворяются, они может смягчить некоторые из ударов by спрашивающий для Денежная компенсация из поставщик услуг. Для многих организаций это форма гарантии, в которой они нуждаются начать прочные отношения с новинка партнер с кем у них нет работавший до .

Что такое OLA?

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

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

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

В чем разница между SLA и OLA?

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

Ключевые различия между SLA и OLA заключаются в следующем:

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

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

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

4. Соглашения об уровне эксплуатации носят более технический характер, чем соглашения об уровне обслуживания.

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

Давайте попробуем понять эти два термина в другом контексте.

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

Заключение

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

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

В чем разница между SLA и OLA?

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

Раньше этим легко управлять.

Но по мере того, как ИТ-среды стали сложными, для удовлетворения ожиданий клиентов услуги теперь требуют участия нескольких внутренних и внешних групп. Итак, теперь есть не только SLA, о котором вы договорились со своим клиентом, и поддерживающие его внутренние OLA, но и SLA, которые вы как клиент согласовали со своими собственными поставщиками. Эти SLA технически также являются OLA, которые поддерживают SLA, составленное с вашим собственным клиентом.

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

Таблица определения нормативов

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

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

Правила определения нормативов на время решения, время реакции и график обслуживания задаются в разделе «Настройки \ Заявки \ Нормативы обработки заявок (SLA)» на вкладке «Правила определения SLA»

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

При создании заявки, Okdesk мгновенно найдет правило, которому соответствуют параметры заявки, и рассчитает плановые времена решения и реакции по нормативам и графику обслуживания. При изменении одного из определяющих параметров у заявки (например, при изменении типа или приоритета заявки), плановые времена будет пересчитаны исходя из правила, которому будет соответствовать заявка после редактирования. Всё как в дорогих Service Desk системах Enterprise уровня и согласно лучшим практикам ;)

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

Читайте также: