Из времени простоя исключается…

В моей практике составления SLA часто бывают ситуации, когда в документе строки об исключениях из учёта времени простоя разрастаются до большущего списка. Стандартно — «в начальном положении» — этот пункт состоит из двух:

  • технологическое окно;
  • форс-мажорные обстоятельства.

В реальных ситуациях, бывает, что разрастается и за 10 с гаком. Они касаются отказа от ответственности по причинам деятельности (или бездеятельности) третьих лиц по отношению к тому, кто составляет SLA и является ответственным за ИТ-услугу. Давайте рассмотрим укрупнённые примеры:

  • взаимодействие со смежниками (организация работ внутри ИТ-подразделения и внутри организации, между отделами; зависимость от работ);
  •  взаимодействие с внешними подрядчиками (ожидание ответа, ожидание выполнения доработок);
  • действия пользователей (неработоспособность конечного оборудования, неконтролируемое увеличение нагрузки, ошибочные или «кривые» запросы, кладущие базу данных).

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

Рассматривая состав ИТ-услуги, становятся понятными и ограничения Поставщика, связанные с её предоставлением, а с ними и исключения из ответственности. Явно указанные ограничения позволяют управлять ожиданиями Заказчика.

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

Стараемся сделать «длинный список исключений» короче:

  • выстраиваем внутренние отношения – договариваемся, выделяем и закрепляем зоны ответственности подразделений внутри организации;
  • управляем внешними подрядчиками – вносим в контракты с ними соответствующие обязательства, являющиеся проекциями требований SLA, на постоянной основе оцениваем их и пересматриваем;
  • работаем с пользователями и с тем, что они используют – обучаем (в пределах своих возможностей), встраиваем в ПО «защиту от дурака», от перегрузок; оптимизируем архитектуру и ландшафт приложений.

А что думаете вы?

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

PRINCE2 Управление ИТ-проектами на основе PRINCE2

Трёхдневный аккредитованный учебный курс с интерактивным кейсом.
 

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

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

  1. Vyacheslav Potov

    По моим наблюдениям, часто вот такие "исключения", на котороых настаивает та или иная сторона растут из вполне конкретных случаев.

    И часто эти конкретные случаи — вопрос Problem Management, просто в более широком понимании. Зачастую изменение процесса (идентификации/эскалации/закупки), помогает привети рассчёт "чистого" SLA к вполне стандартному виду.

     

    0
    0
    1. Денис Денисов Автор

      Обычно, перед непосредственно обсуждением с Заказчиком услуги, не совсем понятен её состав. Мы, как Поставщик, видение своё обычно тоже имеем, но оно может как совпадать, так и существенно отличаться. И ограничения "всплывают" именно на таких детальных обсуждениях между сторонами. Думаю, что клиентоориентированной практикой здесь будет понимание Поставщиком степени "решаемости":

      - если можем обойти ограничения своими силами, то сразу берём на заметку и планируем-делаем;

      - если ограничение требует бюджета — фиксируем в планах по развитию, ждём выделения бюджета, планируем-делаем;

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

      0
      0
  2. Grigory Kornilov

    Есть 3 вида исключений для недоступность сервиса :

    1. Плановые работ по инициативе заказчика. Работы согласуются. Исключение недоступности согласуется с заказчиком при согласовании работ.

    2. Плановые работ по инициативе исполнителя. Работы согласуются. Исключение недоступности согласуется с заказчиком на отчетный период (суммарный, наибольший непрерывный).

    3. Внеплановые работ по инициативе исполнителя. Работы не согласуются. Исключение недоступности согласуется с заказчиком на отчетный период (суммарный, наибольший непрерывный).

    Соответственно п2, 3 мне, как заказчику, не очень интересны в целом причины проведения работ. Если становиться интересно — значит я уже не доверяю заказчику и хочу понять его уровень компетенции как сервис провайдера (есть ли объективные причины увеличившихся downtime) — штраф все равно платиться, но при объективности причин контракт продолжается.

    0
    0

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

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

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

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

ОКТ
26
Учебный курс:
Основы DevOps
ОКТ
30
Учебный курс:
Основы COBIT 5