ola что это значит
Портал №1 по управлению цифровыми
и информационными технологиями
В последние годы я довольно много сталкиваюсь с практическими вопросами организации 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 означает, что Вы «включаете» сервисные отношения внутри ИТ-подразделения. Это имеет довольно серьёзные последствия:
Принимать или не принимать эти последствия решать Вам (это отдельный вопрос в каждом конкретном случае, здесь не может быть универсальной рекомендации). Но осознавать их при принятии решения о применении каталога технических услуг и OLA крайне важно.
Практика
На практике есть компании, которые пытались делать OLA, но они не оправдали надежд. Есть компании, которые обожглись на применении OLA (то есть они не просто не помогли, а помешали). Наконец многие компании называют словом OLA внутренние регламенты взаимодействий, не связанных с сервисными отношениями. То есть, не будучи ясно определён и аргументированно обоснован в первоисточниках, термин OLA вызывает путаницу в реализации.
Лично мне термин OLA представляется просто лишним — SLA и UC абсолютно достаточно. Поэтому берём бритву Оккама и аккуратно отрезаем по шву.
Услуги в сфере ИТ
Магазины, рестораны, аптеки
Госкомпании, органы власти
Это интересно
Компания ALP Group оказывет услуги в сфере ИТ с 1996 года. В настоящее время информационно-технологические услуги, которые предлагают своим клиентам специализированные организации, включают в себя:
Мы заранее определяем какие именно ИТ услуги будут предоставляться той или иной компании, в зависимости от потребностей Заказчика. На их основании можно составить перечень нужных услуг и определить уровень качества обслуживания. Это позволит клиентской организации отказаться от ненужных ей сервисов и остановиться на том уровне обслуживания, которого будет достаточно для обеспечения бесперебойной работы ее информационной инфраструктуры. Это позволяет существенно оптимизировать расходы на ИТ, что особенно важно для большинства отечественных компаний.
Основные услуги в сфере ИТ
Оказание ИТ услуг может осуществляться как в разовом порядке (в форме привлечения обладающего требуемой квалификацией специалиста на какие-либо работы), так и в порядке абонентского обслуживания. Выгоды последнего заключаются в том, что клиентское предприятие может обойтись без внутреннего ИТ отдела либо без штатного системного администратора (в зависимости от масштаба бизнеса). В рамках абонентского обслуживания сотрудник аутсорсинговой компании, осуществляющей оказание ИТ услуг, приезжает в офис заказчика и выполняет обслуживание его информационных систем. Число выездов и часов работы компания-клиент выбирает самостоятельно, в зависимости от своих потребностей. Описание того, какие информационно-технологические услуги будут оказываться, на каком уровне и в каком объеме, а также подробное указание всех остальных условий заранее определяется в составляемом между заказчиком и подрядчиком Соглашении об уровне сервиса – SLA.
В абонентское обслуживание обычно включаются следующие услуги:
SLA, OLA и UC при предоставлении информационно-технологических услуг
В большинстве случаев стандарты, согласно которым должны оцениваться ожидания, оптимизация и параметры производительности, должны быть полностью перечислены в каталоге оказываемых аутсорсером услуг, регулируемых Соглашением об уровне обслуживания (SLA) и соглашением об уровне операционного обслуживания (OLA). При ИТ аутсорсинге между специализированной организацией и клиентским предприятием заключается внешний договор (UC).
Стандартная модель SLA обычно содержит:
Соглашение об уровне обслуживания также содержит и спецификацию целевых уровней качества сервиса, в том числе:
Правила предоставления услуг в ИТ сфере при аутсорсинге
Управление ИТ аутсорсингом происходит на основе разработанной по мировым стандартам методологии, основной целью которой является эффективное управление качеством предоставляемых заказчику услуг. Такая методология обладает своими принципами, о каждом из которых следует рассказать отдельно.
Как заставить OLA работать
По информации многочисленных источников, доля доходов ИТ-компаний от предоставления услуг технического сопровождения составляет 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 и SLA один и тот же, но не всякий инцидент возникает из-за ошибки или сбоя программы, поэтому не в каждом случае необходимо привлекать к его устранению сотрудников производства. Создать какие-либо простые правила, которые являлись бы сигналом для привлечения / не привлечения производства к решению инцидента, невозможно. Попытка ввести ограничения по мощности (например, десяток инцидентов производство гарантированно устраняет в срок, а остальные – как получится) является, по сути, неким самоуспокаивающим средством, поскольку вроде бы соглашение OLA соблюдается, но клиент все равно в итоге отказывается от сопровождения, ибо возникший у него инцидент не устранили в срок. Однако показатель мощности все же желательно ввести, но он должен стать индикатором для сотрудников технического сопровождения. Значение показателя мощности должно сигнализировать техподдержке, что не стоит сваливать на производство решение всех инцидентов, передавать нужно только те, с которыми самостоятельно точно не справиться. Кроме того, нужно оказывать моральное воздействие на сотрудников, время от времени доводя информацию о том, что не стоит производство «перегружать» работами по обеспечению технического сопровождения, поскольку это может привести к снижению возможностей в других работах, в частности, развитии продукта, что является ключевым бизнес-процессом.
Рекомендации от экспертов. Блог 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.