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

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. Альберт

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

  2. Pavel Solopov

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

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

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

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

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

     

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

    1. Vladimir Kapustin

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

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

       

    2. Andrey Kapustin

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

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

       

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

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

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

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

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

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

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

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

    1. Andrey Kapustin

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

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

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

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

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

    1. Альберт

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

  5. Grigory Kornilov

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

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

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

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

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

Empty