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

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

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

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

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

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

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

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

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

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

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

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

 

 

«VAP: Управление поддержкой ИТ-услуг»
Строим эффективную ИТ-поддержку, оптимизируем существующую

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

  • Альберт

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

  • Pavel Solopov

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

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

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

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

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

     

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

    • Vladimir Kapustin

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

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

       

    • Andrey Kapustin

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

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

       

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

  • Сергей Посыльный

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

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

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

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

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

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

    • Andrey Kapustin

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

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

    • Альберт

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

    • Pavel Solopov

      Как правильно реагировать? Разбираться! А если нет кнута и пряника тоже нет, то надо писать заявление на увольнение – он больше уже не руководитель.

  • Grigory Kornilov

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

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

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


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM