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

Задачка: сложности с календарями

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

День 1.

Пользователь из Владивостока в 11 утра по своему времени обратился в поддержку, первая линия решила, что надо назначить это обращение группе ИТ-специалистов в Москве. Но в это время в Москве еще 3-00 и ИТ-специалисты еще не начали свою работу. Придя в 9 утра по московскому времени на работу, ИТ-специалисты провели диагностику, выявили причину и отправили обращение ИТ-специалистам Владивостока для применения локального решения. Допустим, у них на это ушло 3 часа. Т.е. переназначение случилось в 12-00 по Москве и в 19-00 по Владивостоку. В это время, ИТ-специалисты по Владивостоке уже закончили работу. 

День 2.

Придя утром, ИТ-специалисты Владивостока решат обращение за один час. 

Таким образом,  фактически на решение обращения будет потрачено четыре часа. Но при этом для пользователя оно будет решено только на второй день.

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

Как быть?

  • Самый простой вариант: вообще ничего не обещать пользователям, т.к. если случится еще одно подобное переназначение, то решение не уложится и в сутки. 
  • Можно использовать календари рабочих групп для расчета срока. Но как это объяснить пользователям? Да и нужно ли им знать, что их обращением занимались разные люди из разных часовых поясов?
  • Проблемы будут сняты, если обеспечивать круглосуточную поддержку. Но кто даст ресурсы?

Всегда можно пообещать "с запасом". Т.е. считая, что решаем 4 часа, но могут быть переходы между днями, закладываем еще 8 часов "для верности". Но такие нормативы сложно будет обосновать.

А какие варианты предложили бы Вы в данной ситуации?

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

  • Альберт

    Варианты могут быть разные, всё зависит от количества такого рода запросов и критичности их для бизнеса. Исходим из того что запросы критичные. Если количество запросов небольшое, то можно назначать дежурного специалиста который бы обрабатывал запросы вне рабочее время по Москве (если необходимо можно включить выходные дни), необязательно держать его на рабочем месте, он может это делать из дома или откуда угодно (при современном развитии технологий в компании).

    Если количество запросов большое, то в данном случаи нужно организовывать службу с поддержкой 16×7 (при условии что рабочий день с 9 до 18).

    Нужно посчитать стоимость рисков, вероятность их возникновения и затраты на их устранение, после этого уже оговаривать SLA.

    • Альберт, вариант с дежурным действительно спасет, но есть несколько НО:

      1. Дежурных должно быть несколько – по каждой области ответственности (прикладные системы, сети и т.д.). Иначе придется заводить одного но оооочень умного, который знает все и может решать все обращения.

      2. Выделение дежурного – дополнительные ресурсные затраты. Изменение графиков работы сотрудников, возможно доп. олпата, которые тоже необходимо планировать.

      В итоге, не все на это пойдут.

      • Юрий Ерин

        Дежурных должно быть несколько — по каждой области ответственности (прикладные системы, сети и т.д.).

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

        Выделение дежурного — дополнительные ресурсные затраты.

        Конечно. И пойдут на это те, для кого важно обеспечить поддержку 🙂

         

  • Nargiza Suleymanova

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

  • Pavel Solopov

    Но такие нормативы сложно будет обосновать.

    Что значит сложно обосновать? Если кто-то по каким-то причинам не понимает, сути внутренних процессов, то ему и 15 минут будет сложно обосновать.

    Есть особенности компании, есть особенности организации поддержки, эти особенности объективно обоснованы (будем на это надеяться). По существующей технологии нельзя гарантировать 4 часа. Хотите 4 часа? Изменение технологии будет стоить ХХХ рублей.

    В чём проблема-то?

  • Руфат

    Евгений, полагаю намерено было упрощены стартовые условия задачки 🙂 Если у компании есть филиалы в разных часовых поясах, специалисты 2 и 3 линии поддержки централизованы в Москве, то при составлении SLA с бизнесом в явном виде должны быть определены условия, когда инцидент (или запрос на обслуживание) будет решен за обещанные 4 часа (локальные для обратившегося!) а когда за период существенно больший то есть NBD.

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

    Делегирование функции поддержки пользователей региональному подразделению ИТ обосновано и просто реализуется.

    Вариант увеличения периода поддержки в "Москве" тоже возможен за счет разнесения времени работы специалистов 2 и 3 линии (если у них дублирующий функционал и вообще их больше чем один 🙂 ) – часть начинает раньше (возможно с 7 утра), часть заканчивает работу позже (в 21 или 22 часа). Это всё решается на уровне руководства службы эксплуатации ИТ.

     

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


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM