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

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

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

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

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

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

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

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

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

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

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

Пожалуйста, обратите внимание, что у нас настроено, что SLA только в запросе, в нарядах SLA нету. 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