В условиях всё нарастающей конкуренции работа над качеством услуг — неотъемлемая часть сервисного бизнеса.
Поскольку какие-то усовершенствования невозможно себе представить без метрик и соглашений относительно этих метрик, мы приходим к идее SLA. Давайте обсудим, что это такое и зачем оно на самом деле нужно.
SLA — что это такое?
SLA (Service Level Agreement — соглашение об уровне обслуживания) — внешний документ (существующий между заказчиком и исполнителем), описывающий параметры предоставляемой услуги. «Соответствие SLA» эквивалентно тому, что сервис работает так, что реальные параметры не выходят за пределы заявленных в соглашении диапазонов метрик.
Хотя сам термин SLA появился в ИТ, сегодня такие документы используются для описания самых разных услуг, как в ИТ, так и в других сегментах B2B, например в обслуживании коммерческой недвижимости, при ремонте специализированного оборудования и т.п.
В SLA определяются сроки устранения определенных неисправностей, скорость реакции на обращения, доступность службы поддержки и другие параметры.
Для чего нужен SLA
Фактически SLA определяет характеристики предоставляемых услуг и разделяет ответственность за результаты между заказчиком и исполнителем, а иногда и несколькими исполнителями, независимыми друг от друга. В документе указываются права и обязанности сторон.
Например, если речь идет об обслуживании коммерческой недвижимости, в SLA может быть прописано, что:
- исполнитель обеспечивает текущий мелкий ремонт (замену лампочек, покраску стен и т.п.), обслуживает системы подачи и отведения воды, но не отвечает за кондиционеры и бытовую технику — их обслуживает сторонняя компания;
- к критичным поломкам относится, допустим, прорванная труба отопления или засор слива раковины, и критичные поломки устраняются в течение нескольких часов;
- а к некритичным относятся грязные пятна на стенах; и на их устранение у исполнителя есть 5 рабочих дней.
Зачем SLA бизнесу
Если оплачиваемая услуга имеет SLA, у бизнеса появляется возможность проверить качество сервиса — достигаются ли оговоренные метрики. Действительно ли сервисная компания реагирует на инциденты так быстро, как обещала? Решаются ли все возложенные на нее проблемы?
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 часов»).
Несмотря на различия в детализации и двунаправленность (определение требований для обеих взаимодействующих сторон), часто OLA называют внутренним SLA. Далее мы также будем использовать этот термин.
Что должно быть в договоре SLA
SLA должен содержать описание предлагаемой услуги и определять границы ответственности, ограничив область взаимодействия с пользователями только лишь заранее объявленными объектами или продуктами.
В SLA должны присутствовать:
- Общая информация — о сторонах, которые заключают соглашение;
- Параметры и границы предоставляемых услуг:
- по территориям — например, только в офисе заказчика, но не в домашних офисах его сотрудников;
- по оборудованию — только кассы, но не рабочие станции с 1С;
- по графику — с 9 до 18 по московскому времени, а не круглосуточно;
- по пользователям — заявлять о проблемах могут только указанные лица или весь коллектив компании.
- Критерии того, что услуги оказаны должным образом. Это должны быть измеримые параметры, которые могут оценить как клиент, так и сама сервисная компания. Можно использовать один или несколько параметров из списка:
- сроки реагирования на заявки — время первой реакции, передачи заявки профильному специалисту или решения вопроса;
- время простоя бизнеса клиента — максимальное время, в течение которого бизнес клиента будет простаивать из-за поломки, которая находится в зоне ответственности сервисной компании;
- доступность бизнеса клиента — минимальное время за период, в течение которого бизнес клиента будет функционировать в штатном режиме.
- Описание отчетности об оказанных услугах и процесса предъявления претензий.
- Ответственность исполнителя, в частности штрафные санкции за нарушения (если они предусмотрены).
- Способы работы с претензиями.
Также в SLA должно быть прописано, при каких условиях услуга считается оказанной (когда ответственность исполнителя прекращается).
Чтобы SLA не превратилось в головную боль для всех заинтересованных сторон, важно указывать там реально достижимые параметры услуг, которые обе стороны трактуют одинаково.
Мы не рекомендуем указывать в SLA слишком много параметров или использовать какие-то косвенные показатели, слабо коррелирующие с действиями исполнителя. Они только усложняют работу.
Выбор правильных показателей для контроля, как выбор правильных метрик, требует опыта и понимания ситуации. К примеру, нельзя бездумно мотивировать сотрудников решать задачи клиента быстрее — так пострадает качество решения.
SLI и SLO
Отдельно стоит поговорить о двух количественных показателях.
- SLI — индикатор, который отображает пользовательский опыт. Service Level Indicator позволяет количественно оценить, как работает сервис. Как правило, SLI измеряется в процентах — от 0 (ужасный опыт) до 100 (идеальный сервис).
- SLO (Service Level Objectives) — целевой показатель SLI, к которому стремится компания.
Договор SLA
Раз уж SLA определяет взаимодействие двух сторон — клиента и исполнителя — разберем, как соглашение работает для каждой из них.
Глазами клиента
В рамках SLA заказчик получает метрики предоставления услуги — четкое описание того, за что именно он платит.
Клиенту полезно, что в SLA прописываются сроки исполнения заявок (инцидентных или на обслуживание). Конечно, любой заказчик хочет, чтобы его вопрос решался мгновенно, но соглашение (особенно с несколькими уровнями сервиса) отлично демонстрирует, что «мгновенность» стоит денег, и иногда можно подождать несколько часов, чтобы сделать решение дешевле. Он получает достойный ответ на вопрос: «Почему моя проблема не решена вчера?».
Параметры качества, заложенные в SLA, позволяют сверять ожидания от услуги с реальностью. А кроме того заказчику важна ответственность исполнителя за несоблюдение заявленных параметров (вплоть до штрафов). SLA, в котором ответственности не прописано, — лишь декларация о намерениях. А заявленная ответственность повышает доверие Заказчика к поставщику услуг.
Глазами сервисной компании
С точки зрения сервисного отдела или компании SLA — это набор целевых метрик, к которым стремятся исполнители. SLA на самом деле очень полезно, т.к. наводит порядок не только во взаимоотношениях с клиентом, но и (по цепочке) в бизнес-процессах самой сервисной компании.
SLA может стать основой системы мотивации сотрудников. Тот факт, что указанные там параметры соблюдаются — повод похвалить сервисный отдел, заплатить премии его сотрудникам. А несоблюдение заявленных условий — причина начать внутреннее расследование и депремировать виновных. Важно, чтобы у Вас были инструменты, которые позволят контролировать соблюдение SLA и, в случае нарушения, оперативно находить причину или виновного.
Во взаимодействии с клиентом SLA помогает ограничить зону ответственности.
Типы SLA
Соглашения об уровне сервиса делят на три категории по способу применения:
- Внутреннее. Подобные соглашения заключаются между отделами или подразделениями внутри одной компании. Они помогают разделить между ними ответственность перед бизнесом за достижение общих целей. Как мы отмечали выше, внутренние документы, разработанные для обеспечения внешнего SLA, глубже погружаются в технические детали и определяют обязательства обеих взаимодействующих сторон. Однако часто их также называются внутренними SLA.
- Клиентское. Данный тип соглашения сервисная компания заключает со своими клиентами, прописывая параметры оказываемых услуг. Это наиболее распространенный вариант.
- Многоуровневое. Этот тип соглашения фактически представляет собой несколько SLA для разных уровней взаимодействия в рамках одного документа. Хороший пример разделения уровней сервиса — по скорости реагирования (и, соответственно, цене).
Как написать хороший SLA
Грамотно составленный SLA должен давать в руки клиента контроль над услугой, которую он получает. Желательно, чтобы при этом рычаги контроля были ему понятны — пункты соглашения должны однозначно трактоваться как заказчиком, так и исполнителем.
Пройдемся по основным положениям, которые стоит добавить в SLA.
Как и любой официальный документ, SLA должен четко определять, что входит в само понятие «услуга», кто именно ее оказывает и в чем она заключается. Поэтому начать стоит с определений услуг, ролей и спецтерминов. Эта часть должна отвечать на следующие вопросы:
- Какую услугу предоставляет исполнитель — что, когда и где делает? К примеру, мы говорим об обслуживании сантехники в коммерческой недвижимости. Описываем, что услуга подразумевает ремонт и обслуживание сетей водопровода и водоотведения от вентиля жилищно-коммунальной службы на входе в здание. И указываем, что обслуживание осуществляется на территории заказчика в будние дни с 9 до 18 по Московскому времени.
- Какие предусмотрены ограничения услуги — географические, временные? Предположим, обслуживание и ремонт не производится в праздники и с 20:00 до 7:00 по Московскому времени.
- Есть ли какие-то приоритеты? К примеру, если речь про сантехнику и слегка подтекает кран, то это обращение обычного приоритета. А если прорвало стояк и заливает уже 3 этажа здания, то это явно аварийная ситуация. Если в рамках услуги такие ситуации должны обрабатываться по-разному, надо прописать, что такое обычное обращение, а какая ситуация будет рассматриваться, как аварийная.
- Какое подразделение (или несколько подразделений) исполнителя участвует, в чем его (их) роль?
- Каковы функции сотрудников подразделения? Если упоминаем диспетчеров, объясняем, что их функции — ответ на звонки, регистрация обращения и передача его профильному специалисту.
SLA должен содержать понятные клиенту метрики услуги, характеризующие ее качество. Конкретные примеры метрик зависят от сферы деятельности компании. В сервисном бизнесе зачастую берут за основу время решения проблемы.
Важно, чтобы исполнитель полностью определял соответствие услуги этим метрикам (имел на них влияние). Если вы обслуживаете только кассы, нельзя привязываться в SLA простой всей ИТ-инфраструктуры магазина, потому что в нее входят компоненты вне вашей зоны ответственности. Кассу-то, может, вы и запустили, но если при этом в помещении отключено электричество, сделать ничего нельзя. Поэтому лучше сосредоточиться на конкретных метриках, определяющих именно вашу услугу — скорость восстановления работы кассы после остановки.
Метрики должны быть реалистичными. Если в примере с кассой установить в SLA скорость ремонта в 10 минут, скорее всего соглашение просто не будет работать. Более реалистичное, но короткое время, заставит привлекать опытных специалистов, которые в среднем работают с задачами быстрее. А это стоит денег. В этом смысле SLA — это поиск баланса между интересами клиента, который хочет «вчера», и исполнителя, который не может быстрее (или может, но в ущерб другим клиентам).
Метрик не нужно много. Большое количество метрик запутает исполнителя, он не сможет нормально расставить приоритеты в своей собственной работе, боясь выйти за рамки по какой-то из метрик.
Если в оказании услуги участвует несколько отделов и хочется прописать метрики для каждого, это можно сделать в OLA, задав в SLA только один общий параметр, в который уложится вся последовательность действий. Или задать несколько версий этой метрики в SLA, в зависимости от подключения к решению проблемы новых участников (условно говоря, если проблема уходит на третий уровень поддержки, то допустимое время реакции увеличивается на сутки).
Пример договора SLA
По ссылке представлен пример договора SLA реальной IT-компании. Вы можете создать его копию или скачать на ПК.
Как работать по SLA?
Схема работы по готовому соглашению предельно понятна:
- сообщаем параметры соглашения всем сотрудникам клиента;
- стараемся соблюдать касающиеся нашей стороны метрики;
- постоянно измеряем реальное соответствие параметров заявленным показателям;
- делаем выводы — оптимизируем процессы внутри компании;
- периодически пересматриваем SLA, поскольку идеальное соглашение — как сферическая поддержка в вакууме — недостижимый идеал.
Отметим, что соблюдать SLA проще, если процессы в сервисной компании отлажены. Помогают этому различные инструменты автоматизации, в частности, Help Desk.
Не отпугивает ли SLA клиентов?
Ситуация, когда потенциальный клиент читает SLA и отказывается от возможного сотрудничества может произойти в том случае, если он рассчитывает, что параметры сервиса будут не такими, как описано в документе. Например, заказчик хочет, чтобы сервисная компания отвечала на звонки круглосуточно, даже в праздники, и реагировала мгновенно. Но в SLA компания пишет, что горячая линия работает с 9 до 18 по МСК, причем только в рабочие дни.
Очевидно, что в такой ситуации сотрудничество не складывается из-за завышенных ожиданий клиента. Однако если договор все-таки был бы подписан, ничего, кроме головной боли, сервисной компании он бы не принес. Первый же инцидент показал бы разницу в ожиданиях заказчика и исполнителя. В результате поломка была бы устранена, но заказчик остался бы недоволен и счел исполнителя некомпетентным.
В отличие от обычного договора, SLA на старте фиксирует все параметры, распределяя ответственность.
Плюсы SLA для заказчика и исполнителя
Соглашение об уровне сервиса выгодно как заказчику, так и исполнителю.
Заказчик:
- понимает параметры сервиса, за который платит;
- знает, через сколько будет устранена конкретная поломка;
- имеет возможность привлечь исполнителя к ответственности за нарушения параметров оказания услуг;
- может явно делить ответственность с исполнителем услуг.
Исполнитель:
- задает явные параметры услуги и может учитывать их при распределении обязанностей между своими специалистами;
- не обязан работать по ночам, чтобы не испортить себе имя (если ночные вахты изначально не были прописаны в условиях);
- защищен от необоснованных претензий со стороны клиента;
- может планировать расширение штата в зависимости от пула клиентов;
- готов предоставлять несколько уровней сервиса с разной стоимостью;
- явно разделяет с клиентом ответственность за инциденты.
Чек-лист: важные моменты SLA
При составлении SLA рекомендуем обратить внимание на следующие моменты:
- Начните с частей сервиса и малых групп пользователей. Составляя SLA с нуля, не пытайтесь охватить необъятное. Рассмотрите небольшую группу пользователей и только критичные для них сервисы. Этот первый документ даст базу для дальнейшего развития многоуровневого SLA.
- При выборе KPI постарайтесь посмотреть на ситуацию глазами клиента — выбрать понятные и удобные ему KPI, позволяющие составить представление о характеристиках услуги.
- Информирование о SLA. Не забудьте сообщать о SLA всем пользователям, которых он касается.
- Контроль соблюдения SLA. Не полагайтесь на клиента — контролируйте соблюдение SLA со своей стороны.
- Пересмотр SLA. Соглашение надо регулярно пересматривать, т.к. бизнес заказчика и исполнителя эволюционирует — могут эволюционировать и основные параметры услуг.
Сооснователь и директор по развитию Okdesk. Около 10 лет проработал в компании Naumen, где занимался внедрением ITSM и service desk систем в крупнейших российских компаниях: Полюс, Тинькофф, ЛСР и др. Эксперт в области организации и автоматизации процессов техподдержки, сервиса и выездного обслуживания
В последние годы я довольно много сталкиваюсь с практическими вопросами организации SLM и построения каталога ИТ-услуг. Одним из актуальных вопросов в этой области является назначение и содержание такого документа как Operational Level Agreement (OLA).
Есть бородатый анекдот про хозяйку, которую соседка обвинила в том, что когда та брала у неё горшок, она вернула его треснувшим. Ответ был таков: «Во-первых, это неправда — я вернула его целым. Во-вторых, когда я брала горшок, он уже был треснувшим. И в-третьих, я вообще его не брала». Так вот, про OLA я могу сказать буквально следующее: во-первых, такого документа не существует, а во-вторых применение OLA на практике требует серьёзного анализа целесообразности.
Тезис первый: OLA не существует
В самом деле, OLA — это документ, который определяет обязательства внутреннего подрядчика по отношению к поставщику услуг, который тот предоставляет своим заказчикам (при этом между поставщиком и заказчиком заключены SLA). Однако, если внимательно посмотреть, то с точки зрения подрядчика OLA на самом деле является SLA. Более того, заказчик может рассматривать SLA со внутренним поставщиком как OLA, ведь предоставляемые услуги поддерживают выполнение его операций и в свою очередь могут обеспечивать предоставление услуг внешним клиентам. Поэтому двигаясь по цепочке создания ценности, мы быстро придём к выводу: то, что для меня OLA, для моего подрядчика будет SLA.
Поэтому OLA как самостоятельный документ не существует — это то же SLA, только с точки зрения другого субъекта сервисных отношений. И наличие термина OLA в тех же книжках ITIL вызывает вопрос о целесообразности. Более того, если посмотреть на предлагаемые в книжке ITIL Service Design примеры SLA и OLA (приложение F), мы увидим, что они очень и очень похожи.
Тезис второй: применение OLA требует анализа целесообразности
Если Вы осуществляете реализацию сервисного подхода к взаимодействию с ИТ-подразделением и планируете SLA с подразделениями своей компании, это вовсе не означает, что Вам обязательно понадобятся OLA, и они будут полезны. Особенно если речь идёт об OLA в пределах ИТ-подразделения.
Дело здесь в том, что OLA является соглашением о предоставлении услуг. То есть введение OLA означает, что Вы «включаете» сервисные отношения внутри ИТ-подразделения. Это имеет довольно серьёзные последствия:
- создаётся риск излишней автономности внутренних подразделений, ведь отношения с ними будут строиться почти как с внешними поставщиками услуг, и при этом не будут подкреплены аналогичными средствами влияния (конкуренцией, денежными расчётами или административным влиянием);
- потребуется серьёзно пересматривать все процессы, в которые вовлечено новое внутреннее сервисное подразделение (фактически оно вообще может исключаться из единых процессов управления, требовать изменения порядка функциональной эскалации и так далее);
- возникнет отдельная (часто игнорируемая на практике) задача контроля исполнения внутренними сервисными подразделениями своих обязательств. Задача осложняется тем, что у одного внутреннего потребителя будет несколько внутренних поставщиков и наоборот;
- вероятно, понадобятся изменения в организационной структуре, поскольку решение задач 2 и 3 потребует арбитра — третьей стороны, обладающей и функцией контроля, и соответствующими полномочиями.
Принимать или не принимать эти последствия решать Вам (это отдельный вопрос в каждом конкретном случае, здесь не может быть универсальной рекомендации). Но осознавать их при принятии решения о применении каталога технических услуг и OLA крайне важно.
Практика
На практике есть компании, которые пытались делать OLA, но они не оправдали надежд. Есть компании, которые обожглись на применении OLA (то есть они не просто не помогли, а помешали). Наконец многие компании называют словом OLA внутренние регламенты взаимодействий, не связанных с сервисными отношениями. То есть, не будучи ясно определён и аргументированно обоснован в первоисточниках, термин OLA вызывает путаницу в реализации.
Лично мне термин OLA представляется просто лишним — SLA и UC абсолютно достаточно. Поэтому берём бритву Оккама и аккуратно отрезаем по шву.
Соглашение об операционном уровне
Соглашение об операционном уровне также известен как ОЛА. Целью OLA является обеспечение выполнения соглашений SLA внутри организации поставщика.
Соглашение об операционном уровне — Управление жизненным циклом
OLA – использовать
Соглашения о производительности между заказчиком и поставщиком включены в SLA. Менеджер уровня обслуживания поставщика должен внутренне убедиться, что он может выполнять соглашения SLA. С этой целью он может заключать соглашения, например, с служба поддержки с точки зрения времени открытия а с системным менеджментом о, например, часах работы производственной сети. Таким образом, эти взаимные соглашения включены в УПВ. Если необходимо заключить соглашения с внешним поставщиком, такие соглашения включаются в основной контракт.
OLA – заказчик
Заказчик не участвует в составлении и обработке Соглашения об операционном уровне.
Поставщик OLA
Поставщик оплатит соглашения SLA (см. Статью SLA) должны убедиться, что они защищены. Таким образом, внутреннее заверение может осуществляться на основе Соглашения об операционном уровне. Внешняя гарантия основана на Подкрепляющем Контракте (UC).
Соглашение об операционном уровне – процесс
Подготовка и обработка OLA входит в процесс управления уровнем сервиса.
OLA – заверение
Ввиду центральной роли менеджера уровня обслуживания, процесс управления уровнем обслуживания также становится все более важным для обеспечения соответствия стандартам обслуживания. Соглашения OLA должны быть куда-то вложены. Кто-то должен нести ответственность за организацию, мониторинг и отчетность по согласованным услугам. Для этого услуги должны быть переведены в базовые продукты и задачи управления. Задачи управления должны быть закреплены в процессах и должностных инструкциях.
Соглашение об операционном уровне – Темы
В общем, следующие темы встречаются в OLA.
- Управление документами.
- концепции.
- Цель.
- Предмет соглашения.
- Стороны, заявление и подпись.
- Начало и продолжительность.
- OLA-домен.
- Взаимные услуги.
- Бюджет ресурсов.
- Цель.
- Услуги и продукты.
- Уровни обслуживания.
- Соглашения о производительности.
- Показатели эффективности и стандарты эффективности.
- Отчетность, согласование.
OLA – Шаблон
Пример макета главы OLA приведен ниже.
1 Общий.
1.1 Предмет договора.
1.2 Стороны, заявление и подпись.
1.3 Цель Соглашения об операционном уровне.
1.4 Начало и продолжительность.
1.5 Концептуальная основа.
1.6 Связанные документы.
1.7 Процедуры.
1.8 Документооборот.
2 Описание взаимного оказания услуг.
2.1 Введение.
2.2 Товары, подлежащие доставке.
2.3 Предоставляемая услуга.
3 Взаимные соглашения.
3.1 Введение.
3.2 Показатели эффективности продукта.
3.3 Показатели эффективности процесса.
3.4 Показатели эффективности услуг.
3.5 Показатели административной эффективности.
4 Планирование ресурсов.
4.1 Работоспособность.
4.2 Рабочая нагрузка.
5 Отчеты служб.
5.1 Введение.
5.2 Отчеты о лидах.
5.3 отчет о задержке.
6 Связь.
6.1 Оперативная консультация.
6.2 Тактическая консультация.
6.3 Стратегические консультации.
6.4 Сервисная консультация.
6.5 Консультация по эскалации.
6.6 Соглашение об уровне обслуживания оценки.
6.7 Участники служебного собрания.
6.8 Контактные лица, ответственные лица и адреса.
7 Взаимные обязательства.
7.1 Общие положения.
7.2 Исполнение.
7.3 Информация.
7.4 Занятость персонала.
Вложения
1: Сменить лист.
2: Основные контракты.
3: Базовая таблица.
Объяснение для каждого элемента этого шаблона можно найти в книге «Лучшие практики SLA».
Соглашение об операционном уровне — Контрольный список
Приведенный ниже контрольный список можно использовать для проверки заполнения OLA.
| Nr | Контрольные пункты | Да / Нет |
| 1 | Была ли сформулирована цель Соглашения об оперативном уровне? | |
| 2 | Есть ли ссылка на связанные документы? | |
| 3 | Определены ли конкретные термины, используемые в OLA? | |
| 4 | Была ли указана дата начала и продолжительность (дата окончания) OLA? | |
| 5 | Было ли описано, как будет поддерживаться OLA, кто / что / когда? | |
| 6 | Были ли описаны товары для доставки? | |
| 7 | Были ли описаны услуги? | |
| 8 | Была ли описана частота услуг? | |
| 9 | Были ли описаны усилия по управлению для каждой услуги? | |
| 10 | Были ли описаны задачи управления, которые хотя бы выполнены? | |
| 11 | Для каждого продукта указано, какие задачи управления выполняются? | |
| 12 | Был ли определен контактный пункт для обеих сторон? |
больше информации
книги:
Книга SLA: Лучшие практики SLA, ISBN: 9789071501456
Cloud SLA book: Cloud SLA, ISBN: 9789071501739
Показатели показателей эффективности ИКТ: http://ICT Prestatie Indicatoren, ISBN:9789071501470
обучение:
Обучение SLA: Соглашения об уровне мастер-класса
Обучение мониторингу обслуживания: Контроль мастер-класса
Код:
Скачать PDF (NL): К SLA на уровне пользователя
резюме
статья
УУЗР – Управление операционным уровнем
Описание
Целью Соглашения об операционном уровне (OLA) является обеспечение выполнения SLA внутри организации поставщика. Эта статья содержит контрольный список для проверки заполнения OLA.
Автор
Имя издателя
ITpedia
Издательство Логотип
10 Марта 2009 18:03
10 Мар 2009 18:03
|
Разработка соглашений о предоставлении услуг на операционном уровне базируется на формировании списка инцидентов, определении сроков решения проблем, мониторинге устранения инцидентов и мотивации сотрудников на выполнение этих работ. Чтобы получать 100-процентную отдачу от услуг технического сопровождения, необходимо составить OLA в соответствии со всеми нормами и контролировать их выполнение.
страницы:
1
|
2
| следующая
По информации многочисленных источников, доля доходов ИТ-компаний от предоставления услуг технического сопровождения составляет 25-45%. Это существенная часть бизнеса, и она требует внимательного отношения, основанного на взаимовыгодных для клиента и продавца условиях. Ключевым фактором является “прозрачность” во взаимоотношениях, которая, в частности, подразумевает, что клиенту предлагаются услуги по техническому сопровождению, в которых однозначно определены условия устранения возможных проблем. Имея подобный прозрачный сервис, клиент может прогнозировать собственный бизнес и управлять рисками от возникновения инцидентов.
Как правило, при предоставлении услуг технического сопровождения заключаются соглашения, в которых прописывается какие инциденты и в какие сроки должна устранить ИТ-компания, причем нарушение сроков ведет к финансовым потерям (выплате штрафов).
Идея заключения подобных соглашений не нова, о ней много написано, разработана методология ITIL (Information Technology Infrastructure Library – библиотеки инфраструктуры информационных технологий), но практически отсутствует информация о том, какие условия на предприятии нужно создать, чтобы обеспечить соблюдение этих соглашений. ITIL констатирует, что SLA (Service Level Agreement – соглашение об уровне предоставления услуг) может выполняться только в том случае, если опирается на OLA (Operation Level Agreement – соглашение о предоставлении услуг на операционном уровне). Действительно, в одиночку техническое сопровождение вряд ли может решить все проблемы, возникающие у клиентов, иногда ему требуется помощь от других подразделений компании, в частности подразделений производства.
Формирование перечня инцидентов
Разработку OLA нужно начинать с определения перечня инцидентов, которые должны быть включены в OLA и затем, соответственно, в SLA. Хотя в SLA число инцидентов может быть большим, чем в OLA, но все инциденты, указанные в OLA, должны войти в SLA. Инцидент в данном случае – это специфическое поведение программного продукта, приводящее к отклонению от нормального функционирования бизнеса. Подходы к устранению однотипного инцидента могут быть различными. Возьмем для примера программное обеспечение, используемое для регистрации договоров. В силу каких-либо причин время отклика системы увеличилось и вместо 30 сек. составляет 3 мин. Для одного человека, заключающего договор, такие временные потери терпимы, а для многих, стоящих в очереди, увеличение времени отклика системы становится проблемой. В связи с этим у компании-клиента может возникнуть упущенная выгода, поскольку кто-то из посетителей не дождется своей очереди и уйдет к конкуренту. Такой инцидент должен быть устранен как можно быстрее. А теперь представим, что подобное “зависание” при регистрации договоров происходит, но достаточно редко – скажем, с периодичностью раз в неделю. Это такой же инцидент, причина его возникновения, возможно, та же самая, но его влияние на бизнес клиента меньше, поэтому устранить инцидент нужно, но с этим можно повременить.
Поэтому в список инцидентов, для которых будут установлены строгие сроки устранения, нужно включать только те, которые могут вызвать потери выгоды в бизнесе клиента. Все остальные инциденты относятся к числу терпимых, и причины, породившие их, должны устраняться, но в плановом порядке. К определению списка инцидентов требуется привлечь специалистов технического сопровождения, они лучше производства знают статистику возникновения тех или иных инцидентов в компании и окажут существенную помощь при составлении их списка. После того, как список инцидентов сформирован, требуется произвести их ранжирование по приоритетам устранения. По сути, нужно определить группы инцидентов, для которых устанавливаются различные временные периоды устранения.
Ранжирование инцидентов и сроки устранения
Ранжировать инциденты нужно в зависимости от следующих факторов: степени воздействия и критичности. Степень воздействия определяется объемом бизнеса компании, проблемно функционирующего из-за возникшего инцидента. Критичность является характеристикой качества исполнения бизнес-процессов. Например, CBOSS использует 4 уровня критичности инцидентов: максимально критично, критично, условно критично и не критично.
Уровни критичности инцидентов
| Уровень критичности | Описание |
| Максимально критично | Произошла остановка работы одного или нескольких основных бизнес-процессов компании. Решение требуется незамедлительно (наивысший приоритет). На момент обращения проблема влечет прямые финансовые потери для клиента. |
| Критично | Проблемы, наличие которых представляет угрозу остановки работы основных бизнес-процессов компании, потенциально может повлечь финансовые потери либо нанести урон имиджу клиента. |
| Условно критично | Проблемы, решение которых необходимо компании в определенные сроки или к обозначенной дате (срывается маркетинговая акция, невозможно проведение проверочных мероприятий, требуется подготовка отчетной документации и т.д.). |
| Не критично | Проблемы, которые не приводят к остановке работы основных технологических процессов компании, их решение может быть отложено на срок более одного месяца. |
Источник: CBOSS, 2009
Как развиваются отечественные ИБ-платформы
безопасность
Стоит отметить, что под устранением инцидента понимается предоставление “временного решения”, которое позволит восстановить нормальное функционирование бизнеса. Окончательное же решение по устранению возникших проблем может быть предоставлено и позже, но обязательно должно быть реализовано.
При определении сроков устранения инцидентов нужно учитывать, что сотрудник технического сопровождения будет находиться на связи с клиентом в течение всего времени предоставления решения, указанного в SLA. Рекомендуется вначале определить сроки устранения инцидентов для производства, которые будут установлены в OLA, а затем на их основе разработать сроки предоставления решений в SLA.
Особенности OLA
Большое значение имеет то, как часто специалисты технического сопровождения будут привлекать к устранению инцидентов сотрудников производства. Список инцидентов в OLA и SLA один и тот же, но не всякий инцидент возникает из-за ошибки или сбоя программы, поэтому не в каждом случае необходимо привлекать к его устранению сотрудников производства. Создать какие-либо простые правила, которые являлись бы сигналом для привлечения / не привлечения производства к решению инцидента, невозможно. Попытка ввести ограничения по мощности (например, десяток инцидентов производство гарантированно устраняет в срок, а остальные – как получится) является, по сути, неким самоуспокаивающим средством, поскольку вроде бы соглашение OLA соблюдается, но клиент все равно в итоге отказывается от сопровождения, ибо возникший у него инцидент не устранили в срок. Однако показатель мощности все же желательно ввести, но он должен стать индикатором для сотрудников технического сопровождения. Значение показателя мощности должно сигнализировать техподдержке, что не стоит сваливать на производство решение всех инцидентов, передавать нужно только те, с которыми самостоятельно точно не справиться. Кроме того, нужно оказывать моральное воздействие на сотрудников, время от времени доводя информацию о том, что не стоит производство “перегружать” работами по обеспечению технического сопровождения, поскольку это может привести к снижению возможностей в других работах, в частности, развитии продукта, что является ключевым бизнес-процессом.
страницы:
1
|
2
| следующая
Что такое ОЛА?
OLA — это внутреннее соглашение, которое поставщик услуг создает для своих внутренних команд, чтобы они не нарушали Slas. OLA используется для отслеживания внутренних обязательств по обслуживанию.
Проще говоря, OLA информирует внутренние команды о том, сколько времени им нужно для разрешения заявки. Кроме того, он также информирует о последствиях, если срок истек.
На этом высокотехнологичном рынке предоставление выдающихся ИТ-услуг имеет важное значение. Однако организации должны следовать определенным правилам, чтобы максимизировать производительность ИТ при минимально возможном снижении затрат. OLA (Соглашение об операционном уровне) — это один из процессов, которым должны следовать поставщики услуг.
Зачем нужна ОЛА?
OLA предназначены для согласования действий или участия нескольких групп поддержки для предоставления услуги конечному пользователю с соблюдением предполагаемого SLA поставщика услуг. Это связано с тем, что внутренние группы, участвующие в предоставлении услуги, могут не обязательно знать о фактическом обещанном поставщиком услуг времени доставки.
Такие соглашения необходимы для внутренних команд, участвующих в предоставлении услуги, поскольку они могут не знать фактического SLA поставщика услуг.
Следовательно, OLA используются для оптимизации расчета рабочей силы среди вовлеченных групп, что в конечном итоге поможет внутренним службам выполнять обязательства и по-прежнему предоставлять клиентам услуги в рамках предлагаемого SLA.
Элементы ОЛА
На базовом уровне OLA работает как документ, который действует как запись между сторонами и включает следующие элементы:
Общий обзор казино
Две вещи, включенные в общий обзор, – это цель между сторонами и цель соглашения.
Ответственные стороны
Все заинтересованные стороны будут перечислены здесь, в этом разделе, включая их имена, назначения и роли.
Роли и обязанности поставщика услуг
Этот раздел необходим для получения подробной информации о каждом внешнем и внутреннем поставщике услуг, а также о назначенных им ролях и обязанностях.
Часы работы, время ответа и эскалация
В этом разделе можно указать часы работы, время ответа и политику эскалации.
Отчетность, проверка и аудит
Этот раздел предназначен для ссылки на срок полномочий OLA и определения графика или временных рамок для внутренних аудитов, оценок и отчетов.
OLA и SLA — в чем разница?
Люди часто думают, что OLA похоже на SLA, однако содержание OLA все же отличается от SLA. Посмотрите на изображение ниже, чтобы увидеть различия.
Основные различия между OLA и SLA заключаются в следующем:
Соглашение об операционном уровне (OLA)
- OLA — это контракт между отделами внутренней поддержки для поддержки SLA.
- OLA — это обязательства, касающиеся обслуживания службы.
- OLA определяются для отдельных групп поддержки, которым назначены заявки.
- OLA носят технический характер.
Соглашение об уровне обслуживания (SLA)
- SLA — это соглашение между поставщиком услуг и клиентом.
- SLA ориентированы на гарантию обслуживания.
- SLA применимы ко всему процессу разрешения заявок.
- SLA не носят технического характера.
Как использовать OLA в ServiceOps?
Мы не различаем OLA и SLA в нашем продукте с функциональной точки зрения. OLA являются частью SLA. На приведенной ниже диаграмме показано, как OLA работают в сочетании с SLA.
Время отклика: Время отклика — это время, в течение которого технический специалист должен ответить.
Время разрешения: Это максимальное время, необходимое для разрешения заявки.
Общее время OLA: Общее время OLA предназначено для внутренних команд, чтобы решить проблему.
Общее время SLA: Общее время SLA — это время, согласованное между предоставленной услугой и клиентом для разрешения заявки.
Шаги, связанные с определением SLA
SLA создаются с условиями и критериями эскалации, а также возможностью определения OLA. Вот шаги, необходимые для создания SLA.
1
Установить операционную
Часов
2
Определить услугу
ДОГОВОР
3
Определить операционную
Соглашение об уровне
4
активировать
ДОГОВОР
Установить часы работы:
Перед настройкой OLA важно указать часы работы.
Определить соглашение об обслуживании:
После того, как рабочие часы и условия определены, следующим шагом является определение соглашения об обслуживании.
Дайте определение OLA:
После того, как условия упомянуты, необходимо определить OLA.
Активировать соглашение:
Нажатие кнопки «Создать» автоматически активирует SLA вместе с OLA.
SLA создаются с условиями и критериями эскалации, а также возможностью определения OLA. Вот шаги, необходимые для того, чтобы crServiceOps сделал службы доступными с портала. Всякий раз, когда создается заявка, SLA назначается на основе условий, определенных в SLA. Это означает следующее: есть SLA.
- Билет должен быть назначен в течение определенного времени.
- В случае, если SLA имеет OLA, разрешение должно произойти в сроки, определенные OLA.
- Поскольку OLA предназначены для внутренних команд, нарушения OLA не повлияют на конечных клиентов. Но тикет должен быть разрешен в течение общего времени SLA, чтобы предотвратить нарушение соглашения.
Вспомогательные функции:
- Автоматическое назначение билетов
- Виртуальный агент
- Несколько эскалаций SLA
- Мгновенное уведомление
- Вариант внутреннего чата
Включите свой бизнес с
Интеллектуальное управление ИТ-услугами
Часто задаваемые вопросы
Какова цель соглашения об операционном уровне?
Соглашения на операционном уровне используются для внутренних команд, чтобы убедиться, что SLA не нарушается, а заявки разрешаются в рамках определенного SLA.
Что является примером соглашения об операционном уровне?
Соглашение об уровне обслуживания (OLA) определяет взаимозависимые соединения в поддержку соглашения об уровне обслуживания (SLA).
Что означает ОЛА?
OLA — это сокращенная форма Соглашения об операционном уровне.
- Свяжитесь с нами
- Демо
Мы используем файлы cookie на нашем веб-сайте, чтобы предоставить вам наиболее релевантный опыт, запоминая ваши предпочтения и повторные посещения. Нажимая «Принять все», вы соглашаетесь на использование всех файлов cookie. Однако вы можете посетить «Настройки файлов cookie», чтобы предоставить контролируемое согласие.
Управление согласием
