Перенос сроков

DeadlineУже несколько раз всплывала тема сроков, неважно чего: решения инцидентов, выполнения работ и т.д. И каждый раз когда мы обсуждаем эту тему на семинарах проектирования обязательно возникает вопрос переноса сроков. В основном причина переноса в том, что кто-то не хочет портить статистику/отчетность из-за задержек "по объективным причинам". Особенно ожесточенно вопрос обсуждается, если на горизонте маячит привязка системы мотивации к метрикам, связанным со сроками. 

На досуге задумался о том, что необходимо предпринять, чтобы избежать произвольных переносов сроков до бесконечности. Для примера возьмем наши любимые инциденты. Как мне кажется, есть два основных вопроса на которые надо ответить:

  • Кто?
  • Когда (при каких условиях)?

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

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

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

Итак, КТО? Дать возможность любому ИТ-специалисту бесконтрольно двигать срок, значит вообще потерять значение срока. Одним из вариантов, хоть как-то контролировать это действие — требовать вводить/выбирать причину переноса срока. Но такой подход требует последующего анализа, хотя бы выборочного, на достоверность вводимых причин. С последующим разбором полетов. А значит, скорее всего, рано или поздно такой перенос сроков останется без контроля.

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

Далее, КОГДА? "Когда" раскладывается на два вопроса: "в каких ситуациях" и "на каком этапе обработки". Интереснее всего конечно понять в каких ситуациях перенос сроков допустим.  Соответственно для регламентного срока я бы всегда на вопрос КОГДА давал ответ НИКОГДА, а для планового не ставил ограничения. При этом вероятно стоит озаботиться информированием заинтересованных лиц об изменении планового срока.

Решение такого простого вопроса обычно имеет массу последствий, интересно узнать, а как вы поступаете со своими сроками?

 

 

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

ITIL ITIL Intermediate: Operational Support and Analysis

Учебный курс: эксплуатация и поддержка ИТ-услуг, Service Desk, инциденты, проблемы, операции и запросы пользователей — в ITIL и на практике.
 

Узнайте больше!

Комментарии и мнения

  1. Альберт

    Для того чтобы ответить на вопросы Кто и Когда, нужно посчитать Сколько. А далее матрица полномочий — Кто и влияние на бизнес — Когда. Вот в ответе Сколько могут быть варианты. Обычно тот, кто планирует перенести сроки должен сам обосновать этот перенос.

    0
    0
  2. Pavel Solopov

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

    Но мы можем выделить отдельного человека или группу людей, которые будут рассматривать каждый случай в отдельности и принимать решение. Для этого у нас почему-то ресурсы есть...

    Плюс с выделением отдельного "решающего" по переносу сроков мы получаем такие проблемы:

    1. Время взаимодействия с куратором переноса и время его решения может быть больше чем время на которое переносим срок.

    2. Куратор говорит: "нет переносить нельзя", а исполнитель отвечает: "я рад, но я всё равно не уложусь в регламент".  Схема выродится просто в формальное проставление галочки куратором.

     

    Я бы разрешил исполнителям самим переносить сроки (плановые) как, когда и на сколько они считают нужным. При этом если перенос срока выводит инцидент на какое-то критичное отклонение относительно регламента — эскалировать этот вопрос.

    0
    0
    1. Vladimir Kapustin

      Я бы разрешил исполнителям самим переносить сроки (плановые) как, когда и на сколько они считают нужным. При этом если перенос срока выводит инцидент на какое-то критичное отклонение относительно регламента — эскалировать этот вопрос.

      Именно так и делаем.

       

      0
      0
    2. Andrey Kapustin

      Полностью согласен с Павлом и теской.

      Я бы разрешил исполнителям самим переносить сроки (плановые) как, когда и на сколько они считают нужным. При этом если перенос срока выводит инцидент на какое-то критичное отклонение относительно регламента — эскалировать этот вопрос.

       

      Именно так и делаем.

      0
      0
  3. Сергей Посыльный

    Не согласен я с размышлениями о "регламентном" сроке (в том виде как он здесб сформулирован).

    Да, у нас есть соглашение подписанное по которому мы обязуемся сделать что-то в течении 4-х часов.

    Это SLA и прочее. НО! Если я вдруг договариваюсь с Заказчиком о его переносе для определенного Инцидента (не важно по какой причине, но мы (исполнитель и заказчик) между собой об этом договорились) почему его нельзя перенести?

    Мы пришли к соглашению, что по данному Инциденту переносим "регламентный" срок.

    Перенося срок в системе мы указываем что перенесли и на каком основании.

    Это уже не соглашение, не SLA?

    0
    0
    1. Andrey Kapustin

      Сергей, считаю что теоретически можно процедуру переноса "регламентного" срока сделать частью SLA. Но это будет брррр.

      Нарушение "регламентного" срока (времени закрепленного в SLA) может/должно(и будет)  использовано Заказчиком как формальный повод пообщаться о качестве сервиса (и выплате penalty). Внедрение "процедуры переноса" в SLA заведомо снижает риски Сервис Провайдера и переносит их на сторону Заказчика ( на лицо нарушение определения Сервиса по ITIL 🙂 ). Да и практика прописывания "процедуры переноса" в SLA, мне кажется не распространена, если вообще есть. (Там скорее будет только процедура эскалации)

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

      0
      0
  4. Дмитрий Исайченко

    Мне кажется интереснее другое — что толку переносить сроки? Как правильно реагировать руководителю, чтобы прекратить постоянные переносы сроков? То есть понятно, что кнутом и пряником, но как быть если кнута особого нет (или он просто уже почти перестал действовать)? Эта ситуация — постоянная реальность множества организаций.

    0
    0
    1. Альберт

      Руководителю нужно руководить и не доводить дело до ситуации когда нужно переносить сроки. Если уж это произошло минимизировать воздействие переноса сроков на бизнес. Бывает конечно форсмажор, но на этот случай должен быть DRP.

      0
      0
  5. Grigory Kornilov

    Если это проект, то PM согласует матрицу ответственности RACI (или другие более широкие варианты), так не забываем про план коммуникаций.

    Если это инцидент, то SM согласует SLA и правила эскалации при разчилных уровнях его нарушений.

    PS: Но кому же хочется тратить время на серьезную прорабокту подобного? Потому и делегируется принятие решения на исполнителя, все работает пока исполнитель справляется, а недостатки не критичны.

    0
    0

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

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

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

НОЯ
27
Учебный курс:
Основы ITIL (очно)