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

О важности границ

Опубликовано 3 апреля 2015
Рубрики: SLA, SLM, BRM, Практика и опыт
Комментарии

border_b_wНесколько недель назад довелось ознакомиться с несколькими договорами на оказание услуг. Поставщики – большие, крупные компании. Мой профессиональный интерес вызвали разделы про параметры качества услуг и ответственность поставщика.

Что удивило. Во-первых, критерии с единственными фиксированными значениями. Например, говорится о гарантированной доступности в 99% или о пропускной способности каналов, измеряемой в чётко зафиксированном количестве штук пропускаемых за единицу времени элементов. Ни больше, ни меньше. При этом ни слова о том, что произойдёт либо должно произойти, если та же доступность составит за отчётный период не указанные в договоре 99%, а, например, 98% или 95%. В книгах ITIL говорится о том, что SLA должны быть составлены чётким и недвусмысленным языком. Меньше 99% – услуга точно недоступна? На мой взгляд, здесь есть простор для трактовок. Во-вторых (и я считаю, что это является следствием первого замечания), не прописана ответственность за нарушения гарантируемых характеристик. То есть, конечно, общие слова про соблюдение законодательства РФ там есть, но вот конечной ответственности поставщика за качество предоставляемой услуги там не оказалось.

К чему я это. Да всё к той же бессмертной фразе В. Маяковского про "что такое хорошо и что такое плохо". Составляя договор ли, соглашение ли на оказание услуг, мало лишь указать и присвоить значения показателям качества – нужно их проработать глубже, подобравшись к ним ближе и описав с разных сторон. Наше восприятие так устроено, что разница ощущается на контрасте. Понятия не имея и оперируя описанием только известного белого, трудно себе представить чёрный цвет. Так и здесь: можно провести границу, лишь чётко понимая различия между определёнными значениями измеряемой характеристики ИТ-услуги.

Возьмём, к примеру, такую важную характеристику ИТ-услуги, как доступность. Где будет проходить граница между состояниями "доступность" и "недоступность"? Чтобы ответить на этот вопрос, нужно сформулировать критерии, которые будут описывать эти состояния. Фактически, вешки, разделяющие две различных области. Зачастую, проще и нагляднее это сделать "от противного", описав антипода – вместо высчитывания времени доступности и перевода затем в % – указываем максимально допустимое значение суммарного простоя, пусть будет, навскидку, 4 часа. Бизнесу это очень понятно. Время – деньги. Если "время" вдруг остановилось по причине возникшего простоя, то и поток денег, соответственно, тоже. А это потери, которые можно во многих случаях подсчитать.

Аналогично можно разобрать примеры и с другими характеристиками. Чётко описывая границы, поставщик тем самым обозначает область своей ответственности – без тумана недомолвок и недосказанностей. По моему глубокому убеждению не стоит пренебрегать этим при составлении хорошего SLA.

«VAP: Управление уровнем услуг и каталогом услуг»
Разработка каталога, SLA, метрик качества, расчёт доступности

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

  • Михаил

    Абстрактно это хорошо, но с точки зрения бизнеса поставщика, зачем загонять себя в рамки и увеличивать собственные издержки, если клиент этого не требует?

    • Действительно. Но подобная ситуация может возникнуть не только из-за безразличия заказчика (интересная ситуация), но также и в силу особого положения поставщика, когда он является монополистом или олигополистом. В этих двух крайних вариантах уточнение границ либо не нужно – заказчику всё равно, либо невозможно – поставщику всё равно.

       

  • Андрей

    SLA – service level AGREEMENT. Соглашение – это просто документ, в котором поставщик с потребителем фиксируют согласованное понимание уровня качества продукции. И всё. И я с вмами абсолютно согласен – практического толку от этого ни какого. Уже давно пора переходить к SLC – Service Level CONTRACT,  в котором прписывается не только качество поставляемой продукции, но и  ответственность за её несоблюдение, вплоть до солидарной отвественности за убытки, понесенные бизнесом из-за недоступности требуемой ИТ усулги (за канавой такие примеры уже есть). А пока, в беседах с нашими мобильными операторами, когда в ответ на мой вопрос о нормативных сроках устранения сбоя они говорят что будут стараться максимально быстро, я им предлагаю свой вариант – а давайте я тоже буду платить как только у меня получится?  Почему-то не соглашаются. Платить я должен в срок и регулярно, а они будут – как получится.

    • Думаю, что начинаем работать с формой документа, а не с содержанием. Что придёт на смену SLC, когда снова потребуется чётко зафиксировать границы, вопросы ответственности сторон?
      SLA -> SLC ->  [tbd]? 

      • Андрей

        Отличие контракта от соглашения как раз в том и состоит, что контракт содержит контрактные обязательства – материальную ответстенность за несоблюдение обязателств, границы отвественности и прочее. SLC – это как раз новая форма, отражающая новое содержание. Хотя, ничто вам не мешает добавить контрактные разделы в SLA. Получится новый по содержанию документ со старым названием.

        Идея в другом – SLA без раздела с контрактынми обязательствами – пустая и никчемная бумажка. Либо оно (соглашение) должно идти как приложение к контракту, где сказано, что нарушение параметров качества, изложенных в SLA, влечет наказание в виде… 


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM