Смартсорсинг.ру

Сообщество руководителей ИТ-компаний, ИТ-подразделений и сервисных центров

Статьи в блогах Вопросы и ответы Темы в лентах Пользователи Компании Лента заказов Курс по ITSM

Более
5500 человек являются участниками сообщества Смартсорсинг на данный момент

Присоединиться

Войти с помощью:

Кейсы

SLA в ИТ-аутсорсинге: результаты опроса

Давече мы, как разработчики системы для автоматизации процессов взаимодействия с клиентами ИТ-компаний (простым языком — ServiceDesk со спецификой отрасли) обратились с вопросом к представителям ИТ-компаний, как у них обстоят дела (в действительности) с SLA. Спасибо всем, кто ответил (33 компании). Эта информация поможет нам выбрать верное решение по реализации, о котором напишем позже.

Это кстати набросок одной из иллюстраций к будущему сайту SmartNUT

Сегодня же предлагаю посмотреть на результаты опроса.

Вопросов было 4, но наиболее интересны и информативны ответы были на первые 2.

Используете ли вы SLA

Оговорюсь, что под SLA в рамках опроса подразумевали временные характеристики решения поступающих заявок/обращений. Все тут взрослые люди и понимаем, что вообще SLA это куда больше, чем "нормативное время решения". При этом все понимаем, что в реальной жизни чаще всего SLA это именно "нормативное время решения". Итак, был задан вопрос: "Используете ли вы в своей работе SLA?". На выбор было предложено 4 варианта ответа:

  • Да. SLA в явном виде прописан в договоре с клиентом и мы по договору отвечаем за исполнение этих обязательств;
  • Да. Но в договоре с клиентом они не прописаны. В нашем случае это скорее внутренние нормативы;
  • Двояко — у нас нет как таковых SLA (ни как внутренних нормативов, ни как прописанных в договоре). Но мы вручную выставляем дедлайн для каждой заявки;
  • Нет, не используем. Нам достаточно знать, что заявка есть, мы обработаем её в общем потоке.

Несмотря на то, что при 33-х респондентах выдавать результаты можно лишь с точность до 100/33 % = 3%, мы погрешили. Да простит нас статистика.

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

От чего зависят (либо должны зависеть) нормативы обработки заявок?

Варианты ответов следующие:

  • Норматив должен быть единым для всех клиентов и ни от чего не зависеть;
  • От клиента;
  • От договора;
  • От услуги;
  • От типа обращения;
  • От критичности и срочности.

Результаты следующие:

Такие дела! Если идеи для интересных опросов?

Пишите в комментариях, организуем!

sla, опрос, дедлайн
1

Рубинштейн Кирилл [krubinshteyn], 09 сентября 2011, 14:49

()

Комментарии (9)

  • Аватар

    Батыршин Т И [erthad.livejournal.com], 10 сентября 2011, 22:05

    0
    А как вообще рассчитывается насколько выполнимо SLA при имеющихся «мощностях», есть какой-то пример?

    Допустим, время реакции на инцидент такое-то, время исправления такое-то. Как рассчитать сколько человек нужно для успешного поддержания SLA?
    Ну или обратная задача: есть столько-то человек, какое SLA мы можем обеспечить?
    • Аватар

      Ланцев Андрей [Sansey], 12 сентября 2011, 08:23

      0
      если я правильно понимаю что такое SLA - то тут не может идти речь о времени исправления, только о времени реакции на заявку. т.к. извините - я никогда не подпишусь на то, что я подниму упавший сервер не более чем за 2 часа. т.к. одно дело службу запустить упавшую а другое материнскую плату поменять сгоревшую с переносом всех рэйдов и разворачиванием бэкапов. поэтому в моем договоре четко прописаны регламенты реагирования, но нигде не говорится что это время ВЫПОЛНЕНИЯ заявки. и клиенты это понимают. а уж сколько человек выделить на выполнение SLA и какие регламенты установить - это личное дело каждого. у нас время реагирования на экстренную заявку - 2 часа (с учетом выезда) и 3 часа зимой, т.к. пробки и прочее. это значит что при падении сервера или роутера и отсутствии удаленного доступа мои люди должны быть на месте присутствия заказчика не позднее 2 часов и приступить к восстановительным работам, при этом клиенту сразу же сообщается о тяжести проблемы и времени которое понадобится на ее решение.
      • Аватар

        Исаев Игорь [Igor17], 12 сентября 2011, 11:04

        1
        "поэтому в моем договоре четко прописаны регламенты реагирования, но нигде не говорится что это время ВЫПОЛНЕНИЯ заявки" - это тогда не SLA.
        Вы же сервис клиенту предоставляете - например, доступ в Интернет или электропочту (как наиболее простой случай). Поэтому, если подписались на uptime почты 99.9% - значит обеспечьте, и не важно, что там у Вас сгорело. А вот как это обеспечить - это уже совсем другой вопрос - про это, как я понимаю, Тимур и спрашивает. Только думаю, для успешного поддержания SLA, кроме необходимого кол-ва сотрудников, надо иметь и другие активы - например, резервное оборудование, спец ПО и т.п.
        • Аватар

          Ланцев Андрей [Sansey], 12 сентября 2011, 11:25

          0
          ааа... сорри. не понял суть вопроса. с вами абсолютно согласен. если клиент "требует" четкого регламента на ВЫПОЛНЕНИЕ заявки, но при этом у нет и близко нет резервного фонда, то в этом случае работает схема описанная мной выше. если же у клиента имеется резервный фонд либо все сервисы построены на высоком уровне (рэйды, бэкапы, ИБП, кластеры и т.д.) - то в этом случае я готов подписаться на SLA и все что из этого вытекает. но обычно (95% случаев) когда клиенту начинаешь объяснять что требуется для того, чтобы он получил требуемые гарантии и сколько это будет ему стоить - вопрос сразу отпадает. редкие компании имеют в резерве сервера или даже обычные ПК и еще реже встречается клиент у которого выделен стандартный бюджет на поддержку и развитие ИТ (скажем 50 000 ежемесячно). держать же в резерве собственное оборудование не имеет большого смысла (хотя такие вещи как свичи, пилоты, ПК, принтеры мы имеем про запас и это оплачивается клиентом как "резервирование оборудования". по требованию привозим и меняем из своего фонда), но согласитесь мало кто будет держать на складе сервер НР за 180 000 и импульсный ИБП к нему за 50 000 только для того чтобы в случае чего предоставить его клиенту. и опять же это все бесполезно, т.к. простой неизбежен на время разворачивания бэкапов на резервном оборудовании, неважно - клиентском или нашем. железо нужно "строить" так, чтобы оно не дохло, а если и дохло то частями)))... Совсем недавно пришлось отказаться от контракта на обслуживание довольно крупной компании (более 60 серверов в 4 точках), именно из-за того, что они требовали SLA (в том понимании как оно есть, максимальное время простоя сервера 2 часа!!!), но при этом у них нихрена абсолютно небыло и на вопрос "как мы это должны им обеспечить?" они отвечали - вы аутсорсеры, вы и думайте... в общем не срослось))) а жаль)))
          • Аватар

            Исаев Игорь [Igor17], 12 сентября 2011, 11:56

            0
            "Совсем недавно пришлось отказаться от контракта на обслуживание довольно крупной компании (более 60 серверов в 4 точках), именно из-за того, что они требовали SLA (в том понимании как оно есть, максимальное время простоя сервера 2 часа!!!), но при этом у них нихрена абсолютно небыло"
            - можно было заложить стоимость покупки этого резервного оборудования в их абонентскую плату, амортизировав его таким образом за 2-3 года. Это же оборудование, кстати, можно использовать и для выполнения SLA по другим клиентам.

            "в общем не срослось))) а жаль)))" - но ведь с кем-то же они договорились???? Или перестали настаивать на SLA, который не могут оплачивать...

            Кстати - "более 60 серверов в 4 точках" - также можно было бы внедрить у них технологии визуализации - резервировать/восстанавливать сервера стало бы гораздо проще.
            • Аватар

              Ланцев Андрей [Sansey], 12 сентября 2011, 13:29

              0
              ни с кем они не договорились. у них имеется текущий ИТ-отдел на 7 рыл, который зарплату получает, а нихрена не делает. вышли на нас по рекомендациям партнеров, которых мы успешно обслуживаем. суть заключалась в том, что они хотели разогнать ИТ-отдел и полность пересесть на аутсорс, но за малые деньги. а т.к. их ИТ-отдел "запустил" систему дальше некуда, то я не рискнул за них браться. да, можно было бы заложить стоимость оборудования, как вы сказали, в их абонентскую плату - но во-первых где гарантии, что текущее оборудование продержится 2-3 года пока окупится резервное, из своего кармана закупаться сразу тоже не резон, т.к. гарантий, что этот клиент через год не передумает и не свалит тоже нет, а мы останемся с этим дорогущим оборудованием. ну и самое главное - не сошлись в цене. почему-то у них сложилось впечатление, что аутсорс работает реально за копейки в чем я их собсно и разочаровал)))... в общем мне репутация встала дороже, чем призрачная прибыль от такого клиента... я назвал честную цену - они отказались.
      • Аватар

        Котельников Илья [iluha], 12 сентября 2011, 11:15

        0
        SLA бывает разное. Вы говорите о времени реакции на обращение. Очень круто, что оно фиксируется и соблюдается. А можно зафиксировать в договоре и время решения проблем. Соглашусь, Андрей, зафиксировать время решения ЛЮБОЙ проблемы клиента - это может быть сложно. Но никто не мешает поделить заявки на типы до той степени, чтобы можно было с уверенностью говорить о каких-то строгих сроках решения на каждый тип. Правда, если сделать слишком сложную структуру классов и времени реакции, продавать ее  станет слишком сложно...
        В реалиях российского бизнеса зафиксировать время реакции на обращение достаточно, чтобы предоставить на рынок конкурентоспособный сервис, но рынок ит-услуг развивается очень динамично и если не внедрять новых практик - в какой-то момент можно обнаружить себя в хвосте... Правда времени еще вагон - поворот к массовому улучшению сервиса начнется не ранее, чем произойдет насыщение спроса на ит-услуги предложением и закончится экспансивный рост рынка. Но готовиться уже можно :)...
    • Аватар

      Котельников Илья [iluha], 12 сентября 2011, 11:20

      0
      Как рассчитывать - это зависит от конкретной фирмы, конкретных клиентов и конкретного бизнес-процесса. Любой расчет SLA начинается с осознания степени формализации бизнес-процессов организации и сбора статистики обслуживания. 
  • Аватар

    [], 12 сентября 2011, 11:31

    0
    SLA, по большому счёту,способ привлечения и удержания клиента. Оно д.б. гибким. Но в первую очередь должно основываться на технических возможностях провайдера (обученый персонал, гарантийный запас оборудования, заинтересованность сотрудников и др.). Бесмысленно говорить об SLA, когда ничего этого нет, а клиента "откровенно дурят".

© 2010-2017, Смартсорсинг.ру. Сообщество руководителей ИТ-компаний, ИТ-подразделений и сервисных центров