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

Как корректно настроить часовые пояса в ITSM-системе: по заказчику или по исполнителю работ?

В редакцию портала поступил вопрос:

Как корректно настроить часовые пояса в ITSM-системе: по заказчику или по исполнителю работ?

Друзья! Есть ли у кого опыт настройки в ITSM-системе разных часовых поясов? Дело в том, что у нашей компании география по всей России и Центры экспертиз (рабочие группы) есть в нескольких часовых поясах.

Вопрос: в запросе SLA должен тикать по часовому поясу ответственного за запрос или по часовому поясу инициатора запроса?

У нас мы настроили таким образом, что в рамках запроса есть наряды (могут быть назначены на разные Центры экспертиз). За запрос отвечает тот ЦЭ куда направили первый наряд (альтернативы пока не придумали) с возможностью передачи ответственности за запрос.

1) Если настраиваем регламентное время запроса по часовому поясу инициатора запроса (пользователя), то есть риск, что наряд может выполняться Центром экспертизы, живущим в другом часовом поясе и ЦЭ (центры экспертиз) будут жаловаться "нам что ночью работать?"

2) если настроим регламентное время по часовому поясу ответственного за запрос, то непонятно, как быть с нарядами? Ведь SLA только в запросе (в нарядах его нет) и может получиться, что один наряд попадет в тот же часовой пояс, что и ответственный за запрос, а другой наряд будет выполняться другим регионом РФ и мы опять же наткнемся на вопрос "нам что ночью работать?"

Может настроить астрономическое время?

Коллеги, а как у вас?

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

Спасибо.

«VAP: Управление уровнем услуг и каталогом услуг»
Разработка каталога, SLA, метрик качества, расчёт доступности

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

  • Яков Рутман

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

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

    • В ITSM-системе часовые пояса нужно настраивать не по заказчику или исполнителю, а по согласованному SLA…

      +1.

      • Анна

        Яков, верно ли я поняла, что ит директору имеет смысл спросить заказчиков – в какое время они хотят получать услуги и зафиксировать это в сла? Можете плз конкретно сформулировать: что именно нам пошагово нужно сделать? Спасибо

        • Яков Рутман

          Анна, вам нужно наладить процесс управления уровнем услуг. На базовом уровне это можно сделать, предприняв следующие шаги. 
          Для каждого часового пояса определить набор групп сотрудников (исполнителей). Эти группы будут работать в одном-двух часовых поясах. Получая наряды из вашей централизованной ITSM системы.
          Что же касается ЦЭ. Их необходимо организовать таким образом, чтобы часы работы этих центров совпадали с часовыми поясами всех ваших клиентов. Это могут быть распределенные центры (3-4 в зависимости от объемов и часовых поясов), либо вы можете создать один централизованный ЦЭ, который будет работать в часы работы всех ваших заказчиков. Многие компании, с которыми я работал, именно так и поступили.
          Далее для каждой услуги необходимо определить те группы поддержки, которые будут отвечать за поддержку услуги в каждом часовом поясе. При распределении ответственности за запросы учитывать часовой пояс клиента или его местоположение, связанное с часовым поясом (что логичнее), оперируя т.н. «субъектом поддержки», указывающим соответствие местоположения и услуги ответственной группе.
          При такой внутренней подготовке процесса управления уровня услуг с клиентом останется подписать «сквозной SLA». Ответственного же за исполнение запроса возможно будет назначать исходя из субъекта поддержки.

          • Яков Рутман

            Чтобы меня не закидали тапками исправлюсь: не уровень услуг, а уровень предоставления услуг.

    • Яковлев Андрей

      С языка сняли "часовые пояса по SLA" век живи, век учись. Кто то даже не знает, что Заказчик сервисное окно купил, а излучение спутника Дебриса (с) – проблема Исполнителя. 

  • Сергей

    У нас этот вопрос решен просто.

    В ИТ Настраивается по тому как прописано в договоре с контрагентом. Т.е это преджмет торга с заказчиком.  И фактически есть ряд услуг для определенных заказчиков поддержка которых идет вне зависмости от часового пояса заказчика и исполнителя (они тоже в разных часовых поясах) а по Московской часовому поясу. Но при этом тут достаточно жесткие условия по другим составляющим и более мягкие для контрагента по финансам. Но более 99 % процентов SLA (Объем 600 ДЗО в среднем по 20 услуг) идет по часовому посу заказчика. С моей точки зрения все-таки ИТ не ЖЭК, у вас вода течет? Перезвоните через час у нас обед.

    Не ИТ (Централизованная Бухгалтерия, кадры и так далее) – тут SLA предмет договора и но может меняться не только в зависимости от часового пояса Заказчика но даже календарных дат (сдача налоговой отчетности, подготовка ЗП и другие примеры). Мало того еще есть и ограничения по тому в каой рабочей группе выполняется этап Стандартного запроса, так как ряд этапов выполняется локальными представителя заказчика на его площадках с особыми графиками работы. Т.е. у централизованных заданий свой график, а у децентрализованных свой. Но этот механизм работает только в рамках Стандартных запросах (или Изменений).

  • ДМБ

    Если вы предоставляете услуги с 9 до 18 по Москве – то и считать их надо по Москве.

    Если заказчику надо 24х7 – то это стоит денег. Заплатит – будет 24х7.

    Система для учета SLA, а не SLA для отражения как считает система…


Добавить комментарий для СергейОтменить ответ

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM