Как мы писали SLA

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

Итак поехали:
1. Предмет соглашения (здесь все предельно просто)
ООО "Зеленые тапочки", именуемое в дальнейшем «Заказчик», в лице генерального директора Козюпы В.А., действующего на основании Устава, с одной стороны, и ООО «Рога и копыта», именуемое в дальнейшем «Исполнитель», в лице генерального директора Пупкина А.С., действующего на основании Устава, с другой стороны, заключили настоящее Соглашение об уровне предоставляемого сервиса в рамках действующего Договора ИТ-аутсорсинга. Настоящий документ определяет критерии оценки качества услуг и их стоимости, оказываемых в соответствии с Договором, и является неотъемлемой частью Договора. Данное Соглашение отменяет заключенные ранее соглашения об уровне предоставляемого сервиса и стоимости работ, если таковые имели место.


Обговорили Рабочее время, которое считается общепринятым:
2. Рабочее время
Стороны договорились о том, что рабочим временем является промежуток с 9:00 до 18:00 во все дни, кроме субботы, воскресенья и общегосударственных праздничных дней.


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

3. Метрики сервиса

Стороны договорились об использовании следующих метрик уровня сервиса:
3.1 Время реакции на обращение пользователя – время, прошедшее с момента поступления и регистрации запроса на обслуживание (сообщение пользователя о проблеме) до момента фактического начала работ по факту обращения. Временем поступления обращения считается момент поступления электронного письма на адрес support@pupkinservice.ru, регистрации сообщения через онлайн службу регистрации инцидентов, предоставленную Исполнителем, или телефонного звонка в службу технической поддержки с сообщением о проблеме.

3.2 Время решения проблемы – время, прошедшее с момента фактического начала работ над проблемой до закрытия заявки. Временем начала работы над проблемой считается момент отправки Заказчику уведомления о начале работ. Временем решения проблемы считается момент отправки Заказчиком сообщения, подтверждающего закрытие заявки. Подтверждение или опровержение выполнения работ должно быть отправлено Заказчиком в течение 1 часа с момента поступления от Исполнителя уведомления о выполнении заявки на обслуживание. В противном случае заявка считается закрытой автоматически, и временем закрытия заявки является момент отправки уведомления о завершении работ. Уведомления о начале и завершении работ направляются Исполнителем представителю Заказчика, от чьего имени поступила заявка на обслуживание, по электронной почте телефону или через Службу Онлайн Заявок.
3.3 Время жизни инцидента – суммарное время, прошедшее с момента поступления и регистрации обращения, до момента закрытия заявки на обслуживание.


Теперь те самые уровни сервиса, о которых мы заключаем соглашение:
4. Уровни сервиса
Сервис, предоставляемый Исполнителем, делится на уровни в соответствии с установленными значениями метрик:
Табл. 1.

Уровень критичности
Описание инцидента
Аварийный
  • Полный отказ информационной системы в результате технической или эксплуатационной аварии;
  • Отказ критических сервисов при невозможности удаленного решения проблемы;
  • Частичный или полный отказ сети, в результате которого выведены из строя более 25 % рабочих станций;
  • Полный отказ системы электропитания или аккумуляторного питания;
  • Невозможность загрузки серверов и сервисов в результате перезагрузки или аппаратного сбоя;
Средний
  • Выход из строя одного из резервированных или дублирующих элементов или одного из нескольких элементов одинаковой функциональности;
  • Частичное отсутствие входящей и исходящей связи;
  • Отсутствие связи или канала интернет из-за неуплаты по счетам;
  • Отказ критических сервисов и служб при возможности удаленного решения проблемы;
Низкий
  • Неработоспособность отдельных ПК и сервисов;
  • Программные и аппаратные неисправности, не влияющие на работу Информационной системы в целом;
  • Запросы на установку/удаление ПО, модификацию аппаратного обеспечения.
  • Прочие мелкие и незначительные операции;


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

Наименование уровня сервиса
Наличие удаленного доступа Отсутствие удаленного доступа Неустойка за неисполнение нормативов. (руб./час)
Время реакции Время устранения Время реакции Время устранения
Аварийный 20 минут 1 - 3 час 30 минут 1,5 - 5 часа 300
Средний 30 минут 2 – 4 часа 40 минут 3,5 - 5 часа 200
Низкий 1 час По согласованию 1 час По согласованию 150



Далее описали перечень мероприятий, которые Исполнитель обязуется выполнять (не выполнять) в рамках договора и которые попадают (не попадают) под метрики:

5. Перечень мероприятий

по технической поддержке ИТ-инфраструктуры Заказчика
Исполнитель выполняет по поручению Заказчика следующие мероприятия, связанные с обслуживанием и поддержкой существующей ИТ-инфраструктуры:
• Оказание консультаций пользователям ИС Заказчика, решение проблем пользователей, связанных с функционированием ИС Заказчика и ее составных частей;
• Поддержание работоспособности и доступности основных сетевых служб заказчика на уровне, указанном в данном соглашении.
• Проведение мониторинга элементов и подсистем ИС заказчика, а также профилактических работ, направленных на поддержание работоспособности ИС заказчика в целом;
• Осуществление резервного копирования (в случае предоставления Заказчиком соответствующих программных и аппаратных средств, в распоряжение Исполнителя);
• Информирование Заказчика о необходимости модернизации ИС и ее элементов, а также замены вышедших из строя элементов;
• Консультации по приобретению вычислительной и копировально-множительной техники для нужд Заказчика;
• Поставка компьютерной, копировально-множительной и офисной техники по ценам Исполнителя в соответствии с требованиями Заказчика;
• Установка обновлений системы 1С Предприятие версии ______.(в случае предоставления Заказчиком лицензионных идентификаторов доступа к серверам обновления указанных Программных продуктов).
• Сопровождение продуктов 1С на уровне администрирования ресурсов системы и Базы данных.
• Установка обновлений информационно-правовой системы ___________ (в случае предоставления Заказчиком лицензионных идентификаторов доступа к серверам обновления указанных Программных продуктов).
К работам по осуществлению технической поддержки не относятся работы, связанные с частичным или полным выполнением должностных обязанностей сотрудников Заказчика. В частности, сотрудникам Исполнителя запрещено выполнять по поручению сотрудников Заказчика такие работы как:
• Создание, редактирование, форматирование и прочая работа с документами с использованиями офисных приложений типа MS Word, MS Excel, MS PowerPoint и подобных им;
• Создание и редактирование графических, аудио и видеофайлов, флэш-презентаций и прочих медиа-файлов;
• Редактирование наполнения и верстка web-сайтов, вчт. с использованием CMS;
• Написание и отправка сообщений по электронной почте, ведение переписки от имени сотрудников Заказчика;
• Поиск информации в сети Интернет;
• Размещение файлов на FTP-серверах и скачивание файлов;
• Отправка факсов;
• Распечатывание и сканирование документов, изготовление ксерокопий документов;
• Ремонт оборудования, не относящегося к ИС заказчика;
• Выполнение погрузочно-разгрузочных работ;
• Выполнение курьерских поручений, кроме передачи Исполнителю документов, связанных с исполнением настоящего договора.


Ну и последним штрихом пункт с ценами, но тут уже рассчитывайте на персональную жадность своих коллег.
Нам подобного соглашения было вполне достаточно для того, чтобы оградить себя от непонимания со стороны заказчика и его сотрудников. Данные приведенные здесь это абстрактный набор услуги метрик и не является единственно правильным, он просто отображает направления развития SLA как такового в небольших аутсорсинговых компаниях.
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 30

    +3
    А начинать стоило-бы с расшифровки аббревиатуры SLA или хотя-бы ссылочки на вики
    en.wikipedia.org/wiki/Service-level_agreement

    А вообще конечно-же документ полезный
      0
      Согласен, абревиатуру нужно использовать хотя бы после первого уточнения. Примерно так: Service Level Agreement (в дальнейшем SLA)…
      +5
      Скажите, пожалуйста, были ли клиенты, которые отвалились при прочтении данного документа и ушли к другим подрядчикам?
        +12
        Были, к сожалению. А может и не к сожалению, т.к. такие клиенты являются своего рода троллями от бизнеса и лучше с ними не работать, во избежание проблем.
        +2
        Согласна насчет троллей. Нужно же повышать культуру и тем самым общий уровень качества услуг.
          +2
          Если имеется ввиду культура общения с клиентом, то с этим все в порядке. Просто троллинг со стороны клиента идет от непонимания им разницы работы от студента на все руки и от компании, которая предлагает перечень услуг и устанавливает нормы использования ресурсов исполнителя.
            +2
            Я как-то давно, еще когда занимался аутсорсингом, сделал некоторые выводы для себя juick.com/101O101/753410 В основном, на рынке нужны студенты на все руки(или без онных), чем компания с SLA
              0
              Я тоже считаю, что маленькие компании экономически целесообразным сочтут нанять студента, а компания со SLA может не вызвать интереса, но здесь уже умение продать услугу должно приходить на помощь и грамотные менеджеры. Все относительно и каждый случай уникален.
          +2
          Стороны договорились о том, что рабочим временем является промежуток с 9:00 до 18:00 во все дни, кроме субботы, воскресенья и общегосударственных праздничных дней.

          Серьезный недочет — не указан часовой пояс.
            0
            Услуги оказываются только в Москве и области, да и как я писал — это абстрактный набор данных не описывающий конкретику именно наших услуг.
            0
            Мы обычно добавляем еще пункт описывающий что другие доп. виды работы входящие в договор (но не входящие прямо в список запрещенных) могут быть исполнены на основании T&M по такой-то ставке специалиста.
              +2
              В первом пункте — «заключили настоящее Соглашение об уроне предоставляемого сервиса» — это так задумано для поиска дотошных внимательных заказчиков, или описочка по Фрейду? ;)
                0
                Поправил, но вышло забавно согласен.
                  0
                  На всякий случай, пересмотрите оригинал договора. Во избежание ;)
                    0
                    В оригинале все нормально, я когда писал видимо перекреативил.
                +2
                Хотел про KPI сумничать, но увидел неустойки. Вы это прям в SLA впаяли.

                в таблице 1, напротив низкого уровня, не хватает конкретики:
                — вместо «отдельных ПК», надо указать количество, например не более 3-х
                — «неисправности ПО...», не влияющие на работу _сервиса_. Клиент чаще всего говорит в формате,- «почта не работает». Почта, для него — сервис. Такое будет ближе к их языку. То же самое на аварийном уровне.
                — «Полный отказ системы электропитания или аккумуляторного питания» -> «полный отказ системы электроснабжения, включая системы аварийного питания»
                — «Частичный или полный отказ сети, в результате которого выведены из строя более 25 % рабочих станций;»… или серверов, приведший к отказу одного или более сервисов?
                — «Невозможность загрузки серверов и сервисов в результате перезагрузки или аппаратного сбоя;» -> «программный или аппаратный сбой, влекущий за собой полный отказ одного или более сервисов»
                — «Частичное отсутствие входящей и исходящей связи;» Вообще непонятно о чем. Связь бывает разная.
                — «Отсутствие связи или канала интернет из-за неуплаты по счетам;» Причина не важна, важен сервис. Такой пункт стоит включать в SLA, только если вы им сами услугу доступа продаете. Если договор доступа к сети Интернет заключен между клиентом и оператором связи, то это вообще не ваша боль. Такое описывается в зоне разграничения ответственности. Кстати, где оно? Оно должно быть обязательно, иначе после какой то аварии, причиной которой, например, станет несвоевременно купленный/вообще не купленный клиентом ЗИП, формально — вы будете ответственны за простой, пока этот ЗИП будут добывать. Запросто может попасться тролль, который может начать юридически прокачивать эту формальность.
                  0
                  Спасибо за развернутый комментарий, критика логична. Но я повторяюсь — описанные в метриках и в уровнях данные взяты абстрактно, чтобы более-менее указать направление для самостоятельного составления подобного документа, это не боевой вариант и отношения к нашему реальному SLA имеет мало.
                    +2
                    А что ж вы публикуете «нереальный» SLA? :)

                    Для публикации было б лучше готовить шаблон с «очень общими» формулировками.

                    Кстати, забыл. То что у вас называется «Перечень мероприятий», должно называться «Каталог услуг». Так больше похоже на ITIL будет. И должно иметь стоимость, раз уж вы неустойку в виде денег прописали. Т.е. это тоже должно быть измерено и в одинаковых с неустойками единицах (шт/руб, час/руб).
                      0
                      Скажем так — это один из самых первых и обобщенных «черновиков». Естественно под каждого клиента добавляются разные условия или пункты. «Каталог услуг» — это отдельный документ, в нашем случае. Перечень мероприятий как раз подходящее название для того, что описано там.
                  +10
                  Касательно неустойки, я бы предложил добавить: 150 руб/час, но не более 10% от суммы годового обслуживания

                  Мы на этом сильно влетели :-(
                    0
                    Продумайте также названия уровней сервиса — «низкий» звучит как-то принижено, лучше уж «базовый» или «стандартный» :-)
                      0
                      В боевом варианте самый «униженный» называется «начальный», а вот уровню критичности «низкий» как нельзя хорошо подходит
                        0
                        ок, сорри, читал по диагонали :-)
                      +1
                      Печально то что многие заказчики почитав и поработав по SLA найдут себе другого аутсорсера который не «умничает» и готов лететь по первому зову секретарши чинить курсор мыши…
                        +2
                        Хотел бы я посмотреть, что будет с аутсорсером, который «не умничает», а бегает по каждому зову, когда у него будет хотя бы более 50 клиентов одновременно на поддержке и как этот аутсорсер сможет разрулить одновременную починку 50 курсоров у 50 секретарш )))
                        0
                        Подобный подход демонстрирует компетентность исполнителя, думаю вменяемый заказчик оценит.
                          0
                          Пост интересный, но я не понимаю его связи с управлением проектами. Как впрочем 80% топиков в этом блоге.
                            –1
                            Я долго думал куда его разместить и не нашел ничего более подходящего.
                            +1
                            Пользу SLA (во всех его вариантах и областях применения) переоценить сложно. Текст я бы «прогнал» через юриста (да и от коллег есть несколько комментариев по сущ-ву) и — можно продавать как дополнительный сервис вашей компании для таких же микро-контор :)) Обозвать как-нить в прайсе «Устаканивание ваших отношений с клиентами» :)
                              0
                              Для многих небольших сервисных компаний аббревиатура SLA — до сих пор что-то ругательное. Вот неплохая заметка "Договор SLA или Service Level Agreement. Что это такое?"

                              Only users with full accounts can post comments. Log in, please.