Что такое kpi sla
Ключевой показатель эффективности (KPI) и соглашение об уровне обслуживания (SLA) 2021
Разница между ключевым показателем эффективности (KPI) и Соглашением об уровне обслуживания (SLA) может показаться довольно простым; однако, поскольку мы увидим, что между ними есть достаточно разницы между тем, что вам нужно знать как достаточно хорошо, чтобы обеспечить успех вашей организации.
Ключевые показатели эффективности (KPI)
KPI являются важной метрикой, используемой в бизнесе для определения действий, необходимых для благополучия и успеха организации. KPI используются для привлечения внимания к процессам и задачам, которые, по мнению руководства, будут наиболее важными для достижения заявленных целей и задач. KPI варьируются в зависимости от каждой организации. Например, KPI для компании, которая является публичной, может быть ее ежеквартальной выпиской о прибыли, которая будет отличаться от KPI для частной компании, которая может быть его оценкой среди круга сбора средств. KPI могут также различаться для разных сотрудников в рамках одной организации. Например, главный исполнительный директор (CEO) будет больше интересоваться прибылью как наиболее важным KPI, тогда как менеджер по продажам в той же компании может рассматривать доход как определяющий KPI.
Из-за характера KPI они часто используются для определения целевых объектов, которые являются абстрактными по своему характеру, например, опыт работы с клиентами или время обработки запроса. Идентификация соответствующих ключевых показателей эффективности является сложной задачей. Определение ключевых показателей эффективности, которые будут соответствовать организации, зависит, в основном, от способности организаций измерять показатели. Обычно руководство собирает необходимые задачи и определяет корреляции и причинность между определенными метриками. Хотя в конечном итоге они должны воздействовать на соответствующие ключевые показатели эффективности в реальных сценариях и наблюдать реакцию и поведение, поощряемые KPI.
KPI, которые были идентифицированы и выполнены, должны постоянно обновляться с индикаторами, которые гарантируют, что метрики будут повторно укреплять друг друга и не будут приводить к расточительным действиям или разбавлять фокус с других приоритетов. Кроме того, помимо того, что они легко поддаются количественной оценке и четко измеряются, все ключевые показатели эффективности должны быть четко переданы и четко определены сотрудникам простым, понятным образом. Каждый KPI сотрудников должен включать в себя следующий уровень руководства KPI. Это гарантирует, что все сотрудники будут двигаться к одной и той же цели.
Довольно много организаций ограничивают охват KPI небольшими осязаемыми наборами, оценивающими производительность сотрудников внутри организации. Это связано с тем, что наличие нескольких конфликтующих KPI может отвлечь внимание сотрудника до тех случаев, когда важные показатели игнорируются.
Чтобы помочь противостоять этой общей практике, было бы целесообразно:
Соглашение об уровне обслуживания (SLA)
SLA является юридическим документом между поставщиком любого сервиса и его клиентами, который может быть внешним или внутренним. Это соглашение, документирующее определенный набор услуг, которые поставщик предложит, и изложит стандарты производительности, которые должны выполняться в соответствии с юридическими обязательствами.
SLA оправдывают ожидания как от поставщика, так и от клиента в отношении качества и производительности по-разному.
Несколько признаков, обнаруженных в SLA:
Кроме того, при установлении показателей производительности, SLA может также состоять из непредвиденных ситуаций для устранения времени простоя и надлежащей документации для компенсации клиентов в случае нарушения контракта. Обычно кредиты на обслуживание являются общим решением. Здесь поставщик услуг предлагает кредиты клиенту по расчету, уже указанному в SLA. Поставщики услуг могут предлагать кредиты в соответствии со временем, когда оно превысило гарантию исполнения SLA. В противоположность этому, если поставщик услуг должен был превышать условия SLA и идти выше и выше соглашения, что привело к значительной прибыли для его клиентов, SLA может содержать выплаты и вознаграждения, соразмерные шкале и характеру производительности, которая была превышены.
SLA также содержит сведения о непредвиденных обстоятельствах.Это ситуации, когда SLA гарантирует и помогает налагать штрафы в случае нарушения условий соглашения. Документ может включать случаи, которые различаются от актов терроризма к стихийным бедствиям. Это называется форс-мажорной оговоркой, которая является средством оказания помощи пострадавшей стороне из-за ее контроля.
Кому нужен SLA?
Считалось, что SLA исходят из бума информационной технологии в течение последних полувеков. Поставщики сетевых услуг первыми реализовали SLA, но были широко распространены в разных областях IT и ITeS. Корпоративные ИТ-компании, имеющие первостепенную роль в управлении ИТ-услугами (ITSM), соглашаются с SLA с другими отделами в той же организации. Внутренний поставщик услуг создает соглашение об уровне обслуживания, обеспечивающее количественную оценку, измерение и сравнение с поставщиками за пределами организации. Таким образом, помощь организации получает максимальную отдачу от ее ресурсов.
SLA является важной частью любой организации, которая стремится управлять ожиданиями своих клиентов и помогает определить случаи, при которых они не будут нести ответственность за время простоя или проблемы, связанные с производительностью. Кроме того, клиенты могут воспользоваться этими соглашениями в качестве описания характеристик услуги, легко сопоставимо с SLA других поставщиков.
SLA должно быть одним из двух важных соглашений, которые поставщик услуг должен настаивать на своих клиентах. Многие сервис-провайдеры устанавливают общие условия работы. Часто SLA используется в качестве простой справки с соглашением о сервисном обслуживании поставщика услуг. Если кто-то должен был сравнить соглашения о своей важности, то SLA гораздо важнее в отношении услуг, которые должны предоставляться вместе с метриками, используемыми для измерения их эффективности.
Разница между ними.
SLA обычно является соглашением, которое сопровождает услугу, предоставляемую с течением времени. В этом соглашении обычно указываются конкретные базовые показатели и ожидания, которые поставщик должен достичь, чтобы оставаться поставщиком или поставщиком. Несоблюдение условий SLA с обеих сторон обычно связано с штрафами или даже с отменой контракта.
SLA часто являются частью KPI, но реверс редок.
Примеры:
Заключение:
В наиболее приемлемых случаях SLA, как правило, являются метриками, согласованными и признанными во всей отрасли, и будут связаны с созданием «лучших практик» для их поддержки. Общим примером является то, что SaaS обеспечивает бесперебойную работу на уровне 99,9% на уровне предприятия. Это стало возможным благодаря настойчивости и ожиданию клиентов как минимальной базовой линии для обслуживания.
Однако KPI склоняются к тому, чтобы быть довольно специфичным для каждой организации. Конечно, будут некоторые более высокие показатели уровня, которые являются общими. Общим примером являются возможности развития бизнеса как KPI на разных уровнях организации, ориентированной на маркетинг. Хотя, как правило, KPI, которые важны для мониторинга, уникальны или, по крайней мере, не являются обычным явлением. Довольно часто KPI заметно отличаются для сотрудников в одной и той же деловой вертикали. Регулярная и своевременная обратная связь не только играет важную роль в отслеживании KPI, но и помогает четко формулировать то, что организация ожидает от своих сотрудников. Чаще всего организация отслеживает только 1-2 KPI, чтобы обнаружить, что другие показатели игнорируются, что может быть более критичным для его целей.
Что такое Service Level Agreement
Что такое «Соглашение об уровне обслуживания», известное как SLA, какие метрики чаще всего содержит и почему будет полезно как компании-провайдеру услуг, так и организации-пользователю.
Как расшифровывается SLA
SLA (Service Level Agreement) дословно переводится как «Соглашение об уровне обслуживания (оказания услуги)», то есть это договор об уровне предоставляемого сервиса между компанией-провайдером и организацией-клиентом. Основное отличие SLA от обычного договора состоит в подробно прописанном уровне доступности сервиса и времени реакции на инциденты и раскрывает следующее:
В соглашении SLA в обязательном порядке должны быть указаны сроки для решения инцидентов и определяются штрафы, которые обязуется выплатить компания-провайдер в том случае, если значения метрик, определяющих качество услуги, окажутся ниже заявленного уровня. Все это поможет организации-заказчику минимизировать убытки в случае незапланированного простоя.
Важно помнить, что использование SLA выгодно обеим сторонам:
Происхождение термина SLA
Термин SLA появился из методологии ITIL (англ. IT Infrastructure Library – библиотека инфраструктуры информационных технологий), которая помогает IT-компаниям упорядочивать свои бизнес-процессы.
SLA подробнее всего описывается в стандартах ITIL и COBIT (от англ. Control Objectives for Information and Related Technologies – «Задачи управления для информационных и смежных технологий»), используя которые компании-провайдеры регламентируют большинство своих процессов и выстраивают процедуры дальнейшего контроля выполнением этих процессов и взаимодействием с клиентами.
Для чего нужно SLA
Соглашение об уровне обслуживания в числе первых помогает потребителям сервисов однозначно понимать, на каком уровне предоставляется услуга и оперировать теми же терминами, что и компания-провайдер. Например, IT-компания может составить SLA, в котором будут указаны:
Организация-заказчик в свою очередь сможет контролировать качество предоставления услуги и в случае инцидента не понесет убытки, более того его запрос будет решен точно в заданные сроки.
Что включает в себя типовой SLA
SLA также может быть как частью основного пользовательского соглашения, так и самостоятельным документом.
Чаще всего соглашение SLA включает в себя следующие пункты, каждый из которых рекомендуется прописывать как можно подробнее и однозначнее во избежание двоякого толкования:
При описании уровня качества сервиса, важно указать в SLA такие параметры, как:
Если речь идет об оплате сервиса, то указывается следующее:
Все пункты, описанные в SLA, должны быть иметь цифровые параметры, например, время простоя в минутах, необходимое для проведения плановых работ или перезагрузки сервиса.
Параметры, от которых зависит SLA
Параметры, из которых состоит SLA – это измеримые метрики, отвечающие за уровень качества предоставления услуги. Условно эти метрики можно называть «KPI» для SLA.
Такие метрики позволяют пользователям сервиса понимать, что именно и в каком объеме будет предоставляться. Главное условие соблюдения SLA — значения метрик должны быть известны всем заинтересованным сторонам, то есть находиться в открытом доступе, а описания метрик должны трактоваться однозначно.
В метриках могут указываться, например, время реакции на заявку от организации-заказчика, время решения инцидента и штрафы за явные нарушение соглашения компанией-провайдером.
В случае, когда одна и та же услуга предоставляется с разным уровнем качества (используются тарифные планы разной стоимости), в договоре SLA должны обязательно явно выделяться параметры для разных категорий пользователей.
Рекомендуется заранее определять критически важные сервисы, управление качеством которых будет осуществляться без каких-либо задержек, например:
Доступность услуги
Минимальное время, в течение которого услуга точно будет доступна, является метрикой доступности услуги. Доступность услуги обычно измеряется в абсолютных величинах (часах, минутах, секундах), например, за заданный промежуток времени (месяц, год) услуга будет точно доступна N часов, а время простоя составит X часов за тот же период. Доступность сервиса также может быть измерена в процентах и напрямую влияет на итоговую стоимость сервиса.
В качестве примера доступности услуги рассмотрим уровень надежности дата-центров Tier. Для каждого из четырех уровней дата-центров задана конкретная доступность в процентном эквиваленте.
Доступность сервиса невозможна на 100%. Значение доступности в процентах стремиться к 100% и выражается в виде количества «девяток» процента доступности. Например, доступность 99% и 99,999% может быть обозначена как «2 девятки» и «5 девяток», а доступность в 99,95% — может обозначаться как «три с половиной девятки».
| Уровень надежности дата-центра | Уровень доступности (%) | Время простоя (часов в год) |
|---|---|---|
| Tier I | 99,671% | 28,8 |
| Tier II | 99,749% | 22,0 |
| Tier III | 99,982% | 1,6 |
| Tier IV | 99,995% | 0,4 (24 минуты) |
Кстати, на примере доступности дата-центров учитывается только время простоя, в то время как значения остальных основных параметров заданы по умолчанию. При размещении сервера в Selectel, в стоимость входят:
Время простоя для оборудования, размещенного в дата-центре обычно включает в себя время проведения плановых и ремонтных работ, то есть чтобы снизить длительность простоя компания-провайдер должна закладывать время на подготовку плановых работам. Финальное значение метрики Доступность сервиса показывает не только надежность конкретно используемого оборудования, но и его качество обслуживания.
Время реакции на инциденты
Измеренное время, прошедшее с момента поступления и/или регистрации заявки на обслуживание до момента выполнения самой заявки — это числовая метрика Время реакции на инциденты.
Важный момент, время реакции на инцидент в работе используемого сервиса — не равно времени простоя. Время реакции — одна из составляющих длительности простоя, в качестве другой составляющей может быть, например, время решения проблемы. А объединение совокупности времени всех составляющих является временем жизни инцидента, например, в простейшем случае это может выглядеть как:
В SLA рекомендуется прописывать неустойки за неисполнение указанных метрик, например, если было превышено время реакции на инцидент.
Оценка результата
Оценка результата управления инцидентами обычно определяется следующими метриками:
Время реакции на инциденты для оценки результата рекомендуется разделять на категории в зависимости от важности для работы всего сервиса в целом, например:
Чаще всего время реакции на инцидент в среднем составляет от 10 минут до 1 часа. Если при этом заранее были определены критически важные сервисы, то именно на сбои в их работе должна быть самая быстрая реакция.
SLI и SLO
SLI (Service Level Indicator) – это количественная оценка работы сервиса, которая является корреляцией между ожиданиями пользователей и действительной производительностью сервиса за указанный период времени (месяц, квартал, год).
SLI можно рассматривать в качестве индикатора пользовательского опыта, измеряя его в процентном эквиваленте, где:
Причем стоит помнить, что абсолютные минимум и максимум достижимы только в идеальных условиях, точно также, как и прописанные в SLA 100% доступности сервиса. При постановке целей рекомендуется реалистично смотреть на свой продукт и находить золотую середину.
Иногда измерять уровень обслуживания SLI, представляющий интерес, напрямую не получается и нужно измерять связанную метрику. Например, хотелось бы замерить задержки на клиентской стороне, но можно измерить только задержки на сервере.
SLO (Service Level Objectives) – это значение SLI, которого компания-провайдер хотела бы достичь. При установке SLO рекомендуется указывать реально достижимое значение для каждого конкретного SLI. SLO показывает, с каким качеством фактически работает сервис и/или приложение, в отличие от SLA, который используется для того, чтобы задать тот уровня доступности сервиса, на который смогут ориентироваться все пользователи.
Если у компании-провайдера имеется публично-доступный SLA, то обычно при подготовке SLO рассчитываются прописанные показатели SLA. Достижение показателей SLO напрямую зависит от достижения метрик, указанных в SLA. Если показатели SLO не будут достигаться, то становиться более вероятным и нарушение договорных обязательств, прописанных в SLA.
Плюсы использования SLA для заказчиков и исполнителей
Вместо заключения
SLA на сегодняшний день — один из основополагающих документов, влияющих на выбор большинства IT-услуг, так как отражает их качество предоставления и напрямую влияет на их стоимость.
В SLA указываются метрики предоставляемой услуги/сервиса, допускаемые колебания которых и есть уровень SLA. Например, в соглашении об уровне оказания услуг можно указать, что в случае возникновения инцидента заявка будет принята в течение одного часа в любой день недели или только по будним дням с 10 до 19, в зависимости от оплаченного уровня поддержки сервиса. Сами же метрики рекомендуется указывать близкими к реально достижимым, а не желаемым и рекламно-привлекательным, не забывая о необходимости проведения плановых работ.
Как управлять параметрами SLA через показатели KPI в сервисной компании (часть 1)
Что такое SLA – это согласованный уровень качества предоставления данной услуги. Параметры качества услуги должны быть измеримыми, то есть представимыми в виде числовых метрик в определённый период времени. Мы можем использовать оценку ключевых показателей эффективности (KPI) при работе с SLA, и таким образом, через введение KPI повысить прибыльность сервисной компании.
Мы предлагаем вам готовый инструмент, который позволит собственникам и руководителям упростить на всех этапах управление сервисной компанией, обеспечить постоянный контроль на всех участках работ и постоянную оптимизацию всех процессов. В цикле статей «Описание проекта ELMA KPI для сервисной компании» мы подробно объясним и наглядно продемонстрируем, как с помощью системы KPI повысить прибыльность сервисной компании и качество предоставляемых услуг. Давайте разберёмся, какие параметры входят в SLA сервисной компании и через какие ключевые показатели эффективности можно максимально оптимизировать участки работ.
Таким образом, с помощью введения KPI мы можем управлять оптимальными показателями SLA. Кроме того мы решаем ещё ряд проблем.
Оптимизация бизнес-процессов и снижение добавленной стоимости продукции на каждом участке цепочки. Можно выделить наиболее ресурсоемкие участки, на которых происходит рост добавленной стоимости продукта. Ввести целевые показатели эффективности для лица, ответственного за данный участок, и, таким образом, мотивировать его на оптимизацию и качественное выполнение своих обязанностей. При этом надо понимать, что снижение добавленной стоимости продукта может быть не прямым – где-то это сокращение времени выдачи изделия из ремонта, а где-то повышение квалификации сотрудника.
Внедрение системы KPI позволяет получить конкурентное преимущество за счет повышения качества и сокращения сроков предоставляемых услуг. Повышение качества обслуживания клиентов осуществляется за счет внесения показателей, основанных на элементах обратной связи. Это анализ повторных ремонтов, обзвон клиентов по завершению работ, заполнение анкет. Также это может быть анализ повторных ремонтов. Все это складывается в оценку качества работы как отдельных сотрудников, так и всего сервиса в целом. Поэтому анализируя обратную информацию, полученную от клиентов, мы можем повысить качество предоставляемых услуг и сделать компанию более конкурентоспособной.
Повышение квалификации персонала. Клиенты становятся всё более требовательными. На общую удовлетворённость качеством работы сервисного центра влияет много факторов. Даже самый быстрый и качественный ремонт может испортить низкая квалификация менеджера по приёму изделий. Система оценки квалификации персонала мотивирует его на обучение. Причём, как на прохождение общих курсов компании, так и на саморазвитие. При введении KPI сотрудник понимает, что для увеличения его показателей эффективности, а, соответственно – зарплаты, ему надо повышать свою квалификацию. Это касается всех сотрудников: от менеджеров по работе с клиентами и инженеров, до курьеров и работников склада.
Постоянный анализ и улучшение процессов. Система предоставляет отчёт о текущем состоянии дел в виде легко читаемых таблиц и графиков. Таким образом, мы можем оперативно отреагировать на изменения плановых показателей и во время принять правильное управленческое решение. Возможно, по ряду услуг не дополучаем деньги. Или наоборот. Система позволяет анализировать и постоянно улучшать все участки работ.
В следующей статье мы подробно опишем, как правильно прописать дерево показателей для ключевых должностей компании, настроить матрицу эффективности и связать её с целевым управлением компанией.
Рекомендации от экспертов. Блог Okdesk
В условиях всё нарастающей конкуренции работа над качеством услуг — неотъемлемая часть сервисного бизнеса. Поскольку какие-то усовершенствования невозможно себе представить без метрик и соглашений относительно этих метрик, мы приходим к идее 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 должен содержать описание предлагаемой услуги и определять границы ответственности.
Содержание 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 должен четко определять, что входит в само понятие «услуга», кто именно ее оказывает и в чем она заключается. Поэтому начать стоит с определений услуг, ролей и спецтерминов. Эта часть должна отвечать на следующие вопросы:
SLA должен содержать понятные клиенту метрики услуги, характеризующие ее качество. Конкретные примеры метрик зависят от сферы деятельности компании. В сервисном бизнесе зачастую берут за основу время решения проблемы.
Важно, чтобы исполнитель полностью определял соответствие услуги этим метрикам (имел на них влияние). Если вы обслуживаете только кассы, нельзя привязываться в SLA простой всей ИТ-инфраструктуры магазина, потому что в нее входят компоненты вне вашей зоны ответственности. Кассу-то, может, вы и запустили, но если при этом в помещении отключено электричество, сделать ничего нельзя. Поэтому лучше сосредоточиться на конкретных метриках, определяющих именно вашу услугу — скорость восстановления работы кассы после остановки.
Метрики должны быть реалистичными. Если в примере с кассой установить в SLA скорость ремонта в 10 минут, скорее всего соглашение просто не будет работать. Более реалистичное, но короткое время, заставит привлекать опытных специалистов, которые в среднем работают с задачами быстрее. А это стоит денег. В этом смысле SLA — это поиск баланса между интересами клиента, который хочет «вчера», и исполнителя, который не может быстрее (или может, но в ущерб другим клиентам).
Метрик не нужно много. Большое количество метрик запутает исполнителя, он не сможет нормально расставить приоритеты в своей собственной работе, боясь выйти за рамки по какой-то из метрик.
Если в оказании услуги участвует несколько отделов и хочется прописать метрики для каждого, это можно сделать в OLA, задав в SLA только один общий параметр, в который уложится вся последовательность действий. Или задать несколько версий этой метрики в SLA, в зависимости от подключения к решению проблемы новых участников (условно говоря, если проблема уходит на третий уровень поддержки, то допустимое время реакции увеличивается на сутки).
Пример договора SLA
Ниже представлен пример договора SLA реальной IT-компании.
I. Предоставляемые услуги
В этом разделе мы описываем все работы, которые «IT-консалт» выполняет для Заказчика, и системы, которые находятся у нас на поддержке. По каждому виду работ определяется график и ограничения объема услуг, если они есть. Отдельно оговариваются те работы, которые не входят в нашу зону ответственности.
Исполнитель обязуется оказывать Заказчику услуги по сопровождению программного обеспечения 1С 8 ERP, установленного у Заказчика, на следующих инсталляциях:
Период оказания услуг — с «___» _______ ____ г. — «___» _______ ____ г.
Перечень услуг по сопровождению, время предоставления и ограничения по объему оказываемых услуг указан в таблице:
| Услуга | Время предоставления* | Объем услуг |
| Консультации пользователей по работе с ПО, помощь в решении проблем в части бизнес-процессов: — Приемка на склад — Отгрузка готовой продукции | 24/7 | Не ограничен |
| Консультации пользователей по работе с ПО, помощь в решении проблем в части прочих бизнес-процессов | С 9:00 по 18:00 в рабочие дни | Не ограничен |
| Контроль выполнения регулярных процедур по согласованным регламентам | 24/7 | Не ограничен |
| Мониторинг интеграций с системами Меркурий, EDI, восстановление работоспособности интеграций | 24/7 | Не ограничен |
| Мониторинг и поддержание работоспособности сервера приложений | 24/7 | Не ограничен |
| Ведение пользовательской документации (обновление документации при изменениях в ПО, ведение раздела «FAQ») | Ежемесячно | Не ограничен |
| Выдача и изменение пользовательских прав, ролей (по заявкам ключевых пользователей или службы безопасности) | С 9:00 по 18:00 в рабочие дни | Не ограничен |
| Эскалация вопросов, не относящихся к области компетенции Исполнителя (администрирование инфраструктуры, администрирование БД) | С 9:00 по 18:00 в рабочие дни | Не ограничен |
| Исправление ошибок в программном коде ПО | С 9:00 по 18:00 в рабочие дни | Не ограничен |
| Доработка ПО в соответствии с бизнес-требованиями Заказчика | С 9:00 по 18:00 в рабочие дни | Не более 40 плановых часов в месяц ** |
| Обновление систем на новые версии, поставляемые производителем ПО | С 9:00 по 18:00 в рабочие дни | Не более 2 раз в год |
* Время часового пояса Москвы.
** Плановые часы — часы на выполнение модификации, включая постановку задачи, кодирование, тестирование и перенос модификации на рабочее приложение; плановые часы являются оценкой Исполнителя, в обязательном порядке согласуются с ответственным представителем ИТ-службы Заказчика. Риск превышения фактического времени над плановым находится на стороне Исполнителя. Время на модификации не переносится из периода в период.
В перечень услуг, оказываемых Исполнителем, не входят следующие задачи:
Способы взаимодействия пользователей Заказчика и Исполнителя:
Конкретные почтовые адреса, телефоны и учетные записи для Service Desk определяются в регламенте взаимодействия.
II. Ответственность Заказчика
Здесь мы описываем то, что нам нужно для эффективного выполнения работы — доступы, координатор со стороны заказчика, и так далее. Самое важное в этом разделе — монопольный доступ к коду системы с нашей стороны. Если монопольного доступа нет, после возникновения каких-то проблем можно «не найти концов». Если мы отвечаем за приложение, к нам в дальнейшем все вопросы, но мы должны его контролировать.
Заказчик имеет право:
III. Приоритеты и нормативное время решения заявок
В этом разделе мы описываем принципы очередности выполнения заявок поддержкой, включая разбивку бизнес-процессов Заказчика по степени критичности. Здесь же описывается нормативное среднее время решения заявок и предельная доля тех заявок, которые не уложились в нормативное время.
Приоритет заявок определяется дежурным специалистом Исполнителя, исходя из бизнес-процесса, по которому поступила заявка от пользователя ПО, и характера заявки. Нормативное среднее время выполнения заявок и максимально допустимая доля заявок, время выполнения которых не уложилось в нормативное время, представлена в таблице:
| № | Приоритет | Среднее время решения заявки | Доля просроч. заявок | Виды заявок |
| 1 | Критический | Не более 2 рабочих часов | Не более 20% | Нарушения в работе ПО, которые приводят к неработоспособности одной или нескольких инсталляций в целом. |
Мониторинг и поддержание работоспособности сервера приложений
— Отгрузка готовой продукции
Эскалация вопросов, не относящихся к области компетенции Исполнителя (администрирование инфраструктуры, администрирование БД)
Контроль выполнения регулярных процедур по согласованным регламентам
Мониторинг интеграций с системами Меркурий, EDI, восстановление работоспособности интеграций
Выдача и изменение пользовательских прав, ролей
Обновление систем на новые версии, поставляемые производителем ПО
Ведение пользовательской документации (обновление документации при изменениях в ПО, ведение раздела «FAQ»)
По взаимному соглашению сторон приоритет заявки может быть изменен как в большую, так и в меньшую стороны.
Время решения заявки рассчитывается как разница между датой/временем решения заявки и датой/временем регистрации заявки в ServiceDesk, за вычетом периодов нерабочего времени (в соответствии с графиком предоставления услуг в разделе I) и за вычетом времени нахождения заявки на стороне пользователя:
Доля просроченных заявок рассчитывается как отношение количества заявок данного приоритета, время решения которых больше нормативного, к общему количеству заявок данного приоритета.
IV. Отчетность по услугам
Раздел определяет формат и частоту предоставления отчетов для Заказчика
Отчеты предоставляются Исполнителем Заказчику в табличном формате, в электронном виде и используются Заказчиком для оценки качества предоставляемых услуг.
Отчеты по количественным показателям (раздел III) содержат следующую информацию, в разбивке по приоритетам:
Отчеты по количественным показателям предоставляются Исполнителем ежемесячно до 5 числа каждого месяца. Указанные отчеты оформляются как приложения к актам выполненных услуг, подписываются Исполнителем и Заказчиком.
Дополнительно к количественным показателям Исполнитель собирает информацию о качественном восприятии сервиса. Дважды в год Исполнитель проводит опрос пользователей на предмет удовлетворенности следующими факторами:
Отчеты по качественным показателям содержат информацию по удовлетворенности пользователей, в разбивке по ролям пользователей, а также описание принимаемых мер по улучшению показателей.
Отчеты по качественным показателям предоставляются Исполнителем дважды в год, до 20 июня и до 20 декабря.
Координатор самостоятельно проводит анализ полученной отчетности. В случае необходимости, Координатор может инициировать проведение совещания рабочей группы с представителями Исполнителя услуг по анализу отчетности.
V. Методика оценки качества сервиса
В этом разделе мы определяем то, как мы измеряем качество сервиса. Мы приводим перечень метрик качества, как количественных, так и качественных, и определяем вес (важность) каждой метрики, исходя из бизнеса клиента
Исполнитель обязуется ежемесячно рассчитывать итоговый показатель качества сервиса (QoS), на основании следующего расчета:
| Метрика | Вес метрики |
| Среднее время выполнения заявок 1 приоритета меньше нормативного | 0,1 |
| Доля просроченных заявок 1 приоритета меньше нормативной | 0,1 |
| Среднее время выполнения заявок 2 приоритета меньше нормативного | 0,15 |
| Доля просроченных заявок 2 приоритета меньше нормативной | 0,15 |
| Среднее время выполнения заявок 3 приоритета меньше нормативного | 0,05 |
| Доля просроченных заявок 3 приоритета меньше нормативной | 0,05 |
| Среднее время выполнения заявок 4 приоритета меньше нормативного | 0,05 |
| Доля просроченных заявок 4 приоритета меньше нормативной | 0,05 |
| Доля ответов «Быстрее, чем рассчитывал», «Как и рассчитывал» на вопрос анкеты «Насколько быстро, по Вашему мнению, решаются Ваши проблемы» больше 70% * | 0,1 |
| Доля ответов «Да», «Чаще да» на вопрос анкеты «Снимаются ли Ваши проблемы в работе с системой службой поддержки?» больше 80% * | 0,1 |
| Доля ответов «Да», «Чаще да» на вопрос анкеты «Было ли обращение сотрудников службы поддержки с Вами вежливым?» больше 90% * | 0,1 |
* По данным последнего проведенного опроса пользователей
Итоговый показатель качества (QoS) рассчитывается как сумма весов по тем метрикам, которые были выполнены в периоде.
Исполнитель самостоятельно, без согласования с Заказчиком, определяет необходимый трудовой ресурс специалистов поддержки, консультантов и разработчиков для выполнения указанных метрик.
VI. Стоимость услуг, штрафные санкции и условия оплаты
Основной пункт в этом разделе — это расчет штрафных санкций, которые «IT-консалт» применяет к месячному акту в том случае, если нарушаем метрики качества.
Стоимость услуг Исполнителя составляет ________ (___________) рублей в месяц, без учета НДС.
В случае нарушения показателей качества стоимость услуг уменьшается пропорционально штрафным санкциям, согласно следующей таблице:
| QoS от | QoS до | Штрафные санкции, в % от стоимости услуг |
| 0,8 | 1 | 0% |
| 0,6 | 0,79 | 5% |
| 0,4 | 0,59 | 10% |
| 0 | 0,39 | 20% |
Штрафные санкции могут быть начислены начиная с 3-го месяца оказания услуг. Первые два месяца являются ознакомительным периодом, в котором Исполнитель нарабатывает компетенцию в приложении Заказчика.
В случае изменения объема услуг и/или количества инсталляций, стоимость договора может быть пересмотрена как в большую, так и меньшую сторону.
Стоимость дополнительного сервиса, оказываемого по требованию Заказчика:
Стоимость дополнительного сервиса будет включаться в месячный акт отдельными строками.
Оплата услуг производится Заказчиком путем перечисления денежных средств на расчетный счет Исполнителя в течение 10 (десяти) рабочих дней, исчисляемых с первого числа месяца, следующего за месяцем, в котором Сторонами был подписан без замечаний Акт приема-передачи услуг.
Как работать по SLA?
Схема работы по готовому соглашению предельно понятна:
Отметим, что соблюдать SLA проще, если процессы в сервисной компании отлажены. Помогают этому различные инструменты автоматизации, в частности, Help Desk.