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

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

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

День 1.

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

День 2.

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

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

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

Как быть?

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

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

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

«VAP: Управление поддержкой ИТ-услуг»
Концентрация знаний и опыта без натаскивания на экзамен

Комментариев: 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 не будет опубликован. Обязательные поля помечены *

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • 3 стратегии, которые помогут вашей команде принять метрику потока
      Вам необходимо эффективно управлять рабочими процессами, чтобы иметь возможность постоянно предоставлять ценность своим клиентам. Именно здесь в игру вступают метрики потока. Метрики потока являются основной движущей силой оптимизации процессов.
    • Новая модель предоставления ИТ-услуг: почему вам нужно ориентироваться на продукт
      Традиционно ИТ-организации делят все предоставляемые ими услуги на три уровня: инфраструктура (инфраструктура как услуга), платформа (платформа как услуга) и приложения
    • Как DevOps-командам следует использовать метрики DORA
      С момента выхода в 2018 году книги «Accelerate: Наука о бережливом программном обеспечении и DevOps», показатели DORA, которые она представила, стали популярным
    • Лучше делать хоть что-то, чем не делать ничего
      На конференциях по всяким Agile и DevOps мы часто слышим слово «unlearn» — забудьте то, что вы знали ранее! Измените свои представления о мире! Всё устроено
    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT