Портал №1 по управлению цифровыми
и информационными технологиями

Честность в SLA

Опубликовано 30 января 2014
Рубрики: Обо всём на свете
Комментарии

Не секрет, что одним из наиболее популярных параметров ИТ-услуг, который входит в SLA, является время устранения инцидентов. По этому поводу уже много написано и все, что можно было уже обудили. Но вот в очередном проекте разгорелся жаркий спор о том, что считать временем решения инцидента. Традиционно это время от регистрации обращения до завершения работ специалиста. И вроде бы все логично. Но в этот раз разговор зашел со стороны справедливости :), что привело к спору клиенториентированных и ИТ-сочуствующих. Суть спора проста: считать ли в этом времени:  

  • Время ожидания ответа пользователя на дополнительные вопросы ИТ-специалиста
  • Время выполнения работ внешним поставщиком
  • Время ожидание подтверждения решения пользователем в случае отклонения)

С дополнительными вопросами вроде все просто, раз мы ждем пока отвечает пользователь, а он может это делать долго, например, из-за отпуска, совещаний и  других более важных дел, то это время надо выключать из расчета. Об этом я уже как-то писал и говорил, что надо такие ожидания контролировать, чтобы у специалиста не было соблазна злоупотреблять ими.

С временем выполнения работ внешним поставщиком, на мой взгляд, тоже все просто, пользователю все равно, кто выполняет работу, поэтому время работы внешней команды, в большинстве случаев, должно входить в обещанные в SLA сроки.

А вот с временем ожидания ответа пользователя при завершении решения не все так однозначно. Например:

  • Обращение поступило в 10:00
  • Установлен срок по SLA 14:00
  • В 13:00 специалист закончил работу и пользователь получил подтверждение о решении
  • В 15:00 у пользователя дошли руки до проверки решения и попробовав, он увидел, что что-то недоделано.
  • Вернул специалисту, тот продолжил решение.
  • В 15:15 завершил повторно.

В итоге обращение просрочено, но лишь отчасти по вине специалиста. Если бы пользователь дал ответ сразу, то специалист уложился бы в срок. 

Сторонники клиенториентированности скажут, что так и надо делать, т.к. надо решать качественнее, чтобы не было возвратов.

Защитники чести ИТ скажут, что время ожидания ответа пользователя надо исключить из расчетов, т.к. специалист тут не виноват.

Как обычно, выбирать тот или иной вариант  каждый будет сам. Но вопрос, как мне кажется, достоин рассмотрения при обсуждении такого популярного параметра ИТ-услуг как время решения. А какое решение приняли бы вы?  

ОБУЧЕНИЕ
Учебные курсы и сертификация на русском языке
специалистов по ИТ-менеджменту

Также по теме:

Комментариев: 18

  • Кротов Алексей

    Предлагаемое решение в тех системах, с к-рыми я работал и к-рое кажется мне верным: время пребывания в статусе "Решен" не включается в расчет SLA.

  • Александр Васильев

    Время останавливается, после возврата на доработку – часы запускаются дальше, в рамках тогоже SLA

     

    Как может быть по другому? По новой запускать часы????

  • Константин Нарыжный

    Холивар )))

    В Service Design 4.4.5.3 вот что написано (полужирный мой):

    An incident can only be considered ‘closed’ once service has been restored and normal business operation has resumed. It is important that the restored IT service is verified as working correctly as soon as service restoration is completed and before any technical staff involved in the incident are stood down. In the majority of cases, this is simply a case of getting confirmation from the affected users. However … these could simply be visual checks of transaction throughput or user simulation scripts that validate the end-to-end service.

    исходя из аналогичных предпосылок, я делал так. если инцидент закрыт с первого раза, то в SLA попадает время "решения" (у Евгения 3:15). Если инцидент переоткрывался из-за неправильного\неточного\непроверенного решения, попадает время полного решения (5:15). И, конечно же, каждый переоткрытый инцидент – повод для разбора полетов (как переоткрытая хирургическая операция, например). И большой срок по SLA дает возможность обнаружить такой инцидент скорее.

    ИТ-специалисту, который не может "проверить" решение сам, можно порекомендовать использовать статус "ожидание ответа пользователя", а не "решен" в подобных случаях, когда "доделал, а можить и не доделал".

    • Константин Нарыжный

      Цитата приведена из этой темы: http://www.realitsm.ru/2012/05/expand-your-view , про возобновление. Я исхожу из того, что мы в SLA обещаем как раз срок вместе с возобновлением.

    • Кротов Алексей

      В "ожидании ответа пользователя", если в нем не "тикает" таймер, сотрудник ИТ не заинтересован форсировать ситуацию – дозваниваться до пользователя, обращаться к его заместителю или коллеге и т.д. – т.е. проявлять активность. Ответит – и ладно. Подождет дней 10 – и ОК, время SLA не тикает. А при этом ответ пользователя "нет, вы знаете, не работает" не будет отмечен, как свидетельство ошибочного закрытия. Т.е. можно делать так: тут "копнули" – запрос пользователю; не помогло? "копнем" в другом месте.

      С др. стороны если сотрудник уверен в решении, он переводит обращение в "решен". Теперь в идеале – если я не ошибаюсь, – дело 1ой линии связаться с инициатором и подтвердить, что обращение решено. Но там, где на это не хватало персонала и времени, принимался компромисный вариант – пользователю уходит уведомление о решении обращения. Он может повторно его открыть – вот там "переоткрытый" инцидент для разбора полетов, – и это может быть значительный промежуток времени – до рабочей недели, – либо обращение автоматически закрывается (я в курсе о том, что такой вариант не приветствуется по крайней мере частью экспертов Cleverics, тем не менее). В такой ситуации без активного контроля ИТ не вижу большого смысла накидывать это время на SLA. В случае удаленной ТП у сотрудников может не быть возможности проверить именно на рабочем месте инициатора, а тот может сам не иметь возможности удостовериться в решении сбоя нек-рое время (командировка, занятость и т.д.).

      Я соглашусь, что это точно не идеал и, наверное, есть варианты лучше. Но было бы интересно узнать, как вы устраняете верояность постоянных дерганий пользователя вида "мы перегрузили коммутатор, у вас заработало?", "а теперь мы переткнули патч-корд, есть изменения?" и т.д.

      • Константин Нарыжный

        Алексей, в цитате выше предлагается не задавать эти вопросы пользователю, а "выполнять визуальную проверку пользовательских транзакций, или использовать симулирующие действия пользователей скрипты". 

        Вы правы, что эти варианты вряд ли применимы для сбоев на рабочем месте пользователя (типа сбоев автономного ПО). Но таких инцидентов в целом должно быть немного, и влияние каждого из них невысокое. Поэтому настраивать мотивацию ИТ-специалиста в направлении "помоги каждому пользователю до конца" мне кажется неточным. Пусть он "копнет", а потом не ищет пользователя, а "копает" в других инцидентах. Инцидентов же больше, чем спецов?))))

        • Кротов Алексей

           Пусть он "копнет", а потом не ищет пользователя, а "копает" в других инцидентах. Инцидентов же больше, чем спецов?))))

          Это не работает для аутсорсера – личный пример.

          И непонятно, как это "копнет" должно работать в случае внутреннего отдела. "Копнет", срываяч по факту SLA или максируя его срыв?

           

          • Константин Нарыжный

            Простите, а что значит "не работает"\"должно работать"?

            По сути мы говорим о следующем: "включать или нет продолжительность диагностики в совокупное время исправления услуги или нет". Еще раз подчеркну, что исследовательская хирургия – это исключение, и уж во всяком случае, повод для анализа и документирования на будущее. 

            • Кротов Алексей

              ответ дал ниже, но вроде без уведомления.

  • Кротов Алексей

    Простите, а что значит "не работает"\"должно работать"?

     

    Это значит, что в случае аутсорсинга клиента-заказчика не интересует, почему спец-т ИТ не может найти его сотрудника-инициатора. Спец-т должен активно предпринимать действия, чтобы взаимодействовать с пользователем и в том числе запросить дополнительную информацию или сообщить об устранении сбоя (и не только по почте, а обязательно контролируеммым образом в дополнение- телефонный звонок с записью или с копией на контролера от заказчика).

     

    В случае внутреннего отдела я не сталкивался с такой требовательностью – хотя жаль, – и там принимают компромисный вариант, описанный ранее.

     

    • Константин Нарыжный

      Вот тут мне кажется есть зависимость от:

      – специфики аутсорсинга. Когда вы студент и аутсорсите поддержку рабочих мест в малом бизнесе – тогда personal touch необходим, но обходится заказчику дороже (экономия от масштаба, риски и т.д.)

      – объема поддержки. Когда пользователей – за тысячу, а между ними и аутсорсером (командой экспертов) есть "прослойка" в виде внутреннего ИТ, тогда кмк заказчику (в общем случае нескольким заказчикам, аутсорсинг же) важнее становится не удовлетворенность каждого конкретного сотрудника и не решение каждого конкретного инцидента в срок, а нечто иное 😉 Тут я думаю ваш подход, Алексей, очень быстро расстроит таких экспертов.

  • Кротов Алексей

    Когда вы студент и аутсорсите поддержку рабочих мест в малом бизнесе — тогда personal touch необходим, но обходится заказчику дороже (экономия от масштаба, риски и т.д.)

    Контора, в к-рой я внердял СД, обслуживала > 100 клиентов. Клиенты бли разные – от 10 до 100 чел. Думаю, что несмотря на "неглобальность" бизнеса, называть это "студент в аутсорсинге" тоже не стоит, i think.

    объема поддержки. Когда пользователей — за тысячу, а между ними и аутсорсером (командой экспертов) есть "прослойка" в виде внутреннего ИТ, тогда кмк заказчику (в общем случае нескольким заказчикам, аутсорсинг же) важнее становится не удовлетворенность каждого конкретного сотрудника и не решение каждого конкретного инцидента в срок, а нечто иное

    заказчика, как Вы верно заметили, мало интересует удовлетворенность конкретного его сотрудника, но вот в случае, когда сбой приводит к негативным последствиям для его бизнеса, то данная ситуация его начинает волновать вполне. И почему в данном случае, когда его сотруднику нужн было распечатать срочно какой-то обязательный отчет, с этим сотрудников или его коллегй или рук-телем не связались, не проявили проактивный подход – вот эти вопросы он и задает. И очень быстро аутсорсер либо теряет договор, либо таки старается быть более активным.

    Почему такое замечательный подход к ответственности ИТ не применим внутри конторы? Я только "за".

  • Константин Нарыжный

    называть это "студент в аутсорсинге" тоже не стоит, i think

    Так я и не называл же, я как раз про вырожденный случай "один к одному или к нескольким" =) Но и при подобных вашим масштабах заказчика (100 сотрудников) вот этот персональный подход может быть целесообразен, и метрики "клиентоориентированности" могут и должны быть встроены в SLA, а как следствие – и в инструкции исполнителей, а также в инструмент автоматизации (грубо = статуса "ожидание пользователя" быть вообще не должно). Однако, еще раз: пока специалист ищет пользователя с решением для закладок в браузере, другой пользователь с инцидентом "про отчет" может очень страдать.

     не связались, не проявили проактивный подход

    Так связались же: по почте пришло подтверждение о решении "решение готово, попробуйте, ждём ответа". В кейсе Евгения так.

    • Кротов Алексей

      вот этот персональный подход может быть целесообразен

      Момент – он не персональный, он "заказчико-ориентированный". Если SLA по сервису "доступ в интернет" (т.е.е – ч/з определенный браузер и т.п.) таков, что другой пользователь "про отчет" вынужден пострадать – так тому и быть. А если они оба таковы, что "разбейтесь в лепешку и сделайте" – то либо плохо просчитаны трудовые ресурсы и SLA, либо так карта легла – и будет нарушение SLA  по каком-то из клиентов. Но – обсуждали мы не совсем то.

      Так связались же: по почте пришло подтверждение о решении "решение готово, попробуйте, ждём ответа".

      Вот и вопрос – считать ли это уже решенным обращением? Или ожиданием ответа пользователя после тестирования?

      В 1ом случае – не стоит "тикать" таймеру – IMHO, – т.к. пользователь может:

      1. не ответить

      2. ответить ч/з значительное время

      3. ответить по другому вопросу.

      Хотя да, по приведенному Вами отрыву восстановление сервиса из закрытие обращения может быть зафиксировано только после подтверждения, что нормальное функционирование бизнеса восстановлено. Но – нормировать/контролировать промежуток м/ду solved  и closed можно только в том случае, когда он Вам подконтролен – т.е. Вы можете  передать на 1ую линию или контроль кач-ва задачу по подтверждению восстановления сервиса со стороны заявителя. Если такой возможности нет, то бессмысленно "растягивать" SLA на этот промежуток – пользователь и его ответ Вам неподконтрольны и неуправляемы.

      В 2ом случае таймер должен "тикать", т.к. запрос ответа от пользователя без закрытия обращения подразумевает, что "может работать, а может и нет". И в таком случае риски должны быть на стороне исполнителя, т.к. пользователь, у к-рого не работает сервис, может заниматься другой задачей, может пропустить письмо, может не ответить и т.д. – сервис в это время все также недоступен этому пользователю, а, возможно, и его коллегам. И задача исполнителя до момента устранения предпринимать действия к решению инцидента – в том числе, связываться с имеющими отношение к сбою – вендором, инфрастр-рой и – инициатором.

      • Константин Нарыжный

        пользователь и его ответ Вам неподконтрольны и неуправляемы

        В общем случае, если вы кидаете ответ в пользователя без обратной связи вообще, то появляются сомнения в том, а способны ли вы вообще контролировать уровень услуг и управлять им. То есть, например, появился сигнал, что услуга легла – мы определили "соответствующий" сбой инфраструктуры – исправили инфраструктуру и выключили таймер сбоя. В этой последовательности чего-то не хватает, правда?

        По-моему, Алексей, мы с вами согласились в том, что Евгению нужно ответить: "Да, можно и так и так, как будет удобнее в конкретной ситуации" =)))

        • Кротов Алексей

          В общем случае, если вы кидаете ответ в пользователя без обратной связи вообще, то появляются сомнения в том, а способны ли вы вообще контролировать уровень услуг и управлять им. То есть, например, появился сигнал, что услуга легла – мы определили "соответствующий" сбой инфраструктуры – исправили инфраструктуру и выключили таймер сбоя. В этой последовательности чего-то не хватает, правда?

          Эээ, нет, обратная связь может идти по разным каналам. Впрочем, Вы верно заметили – с основным вопросом мы вроде разобрались.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
Авторы и редакторы портала — консультанты и тренеры компании Cleverics.
Использование материалов данного сайта допускается исключительно с разрешения правообладателя.
Использование данного сайта означает согласие с обязательством соблюдать нашу Политику конфиденциальности и Согласие на обработку персональных данных.