Вам сколько вешать?

В моей продолжающейся практике составления SLA бывают и другие не менее интересные ситуации. Зачастую серьёзные размышления у сторон вызывают выявление и согласование «объёмов потребления» ИТ-услуги. 
    Объёмы потребления – количественные показатели, отражающие в соглашении баланс между возможностями Поставщика при предоставлении и текущими потребностями Заказчика при использовании ИТ-услуги. Зачем их нужно фиксировать в SLA? Для решения задачи ресурсного обеспечения. В условиях, когда объёмы потребления увеличиваются, необходимо при переходе заранее обговорённого установленного порога:
- либо увеличивать ресурсы, необходимые для предоставления ИТ-услуги на согласованном уровне;
- либо договариваться с Заказчиком о снижении требований к уровню ИТ-услуги.
Иначе не избежать недовольства с обеих сторон. Заказчик недоволен снизившимся качеством ИТ-услуги, Поставщик – возросшей нагрузкой, незапланированной и возможно близкой к предельной.

Получается, что вещь-то нужная и для Заказчика, и для Поставщика. Документально зафиксированные объёмы потребления дают ИТ-подразделению возможность иметь больше аргументов:
1) для защиты бюджета на приобретение программно-технических средств или услуг третьих сторон;
2) для выделения дополнительных трудовых ресурсов;
3) при переговорах об изменении уровня предоставления ИТ-услуги с Заказчиком.
А для Заказчика это может быть средством планирования расходов на обеспечение своей деятельности.

 

Делюсь впечатлениями. В обсуждениях при детальной проработке документации по ИТ-услугам я наблюдаю,что представители 

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

Отыскивать и устанавливать эти взаимосвязи, бывает непросто, но оно того, как мне кажется, стоит. А вы определяете, выявляете? Поделитесь, пожалуйста, опытом в комментариях.

 

 

ITIL Expert Уверенная дорога до ITIL Expert
 

Экономия на обучении до 30% для тех, кто хочет быстро добраться до высшей ступени в ITIL
 

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

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

  1. Альберт

    Чаще всего работает такая модель:

    Внутренний заказчик — услуга <= стоимость — ИТ Бюджет — стоимость <= услуга — Внешний поставщик

    В случаи с внутренним заказчиком оговаривается максимальный объем услуг, в случаи с внешним поставщиком чаще оговаривается минимальный объем услуг. На эти 2% мы и живем 🙂

  2. Vladimir Lyaleko

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

    Как заложить динамику изменения уровня потребления в SLA?

    Пересматривать SLA, каждый раз когда нагрузка превысила установленный порог? Придётся либо слишком часто его пересматривать, либо задавать сразу с большим заделом, что не рационально.

    Фиксировать в SLA план роста потребления с разрезом на квартал \ год и т.д?  Фактически Capacity plan включаем в SLA, избыточно получается.

    Какие ещё могут быть варианты ? 

    ИМХО В идеале все указанные моменты решать в рамках процесса Capacity Management, в соответствующих планах (Capacity plan). Конечно итиловскую идиллию, где в качестве самостоятельных документов существуют все три разновидности Capacity plan (Business, Service, Infrastructure) не встречал. Но сводный документ который отражает планы развития мощностей, который согласуется с бизнесом и оперирует термином потребление услуг, встречается довольно часто. 

    И кстати, когда у нас каталог не от ИТ систем, а от бизнес процессов, расчет уровня потребления является совсем не тривиальной задачей, о которую многие спотыкаются и возвращаются к любимым ИТ системам. 

    Хотя может я в другой реальности живу и вообще все не так 🙂 

     

    1. Георгий

      Владимир, все верно, за этот параметр услуги отвечает процесс упр-я мощностями, но это не повод не прописывать эту метрику в SLA 🙂

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

      1. Vladimir Lyaleko

        Конечно здорого её прописывать, более того везде где я нечто подобное встречал, метрика прописана именно ввиде целевого показателя.

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

        У меня в голове укладывается единственное решение, добавлять в SLA календарь потребления. Можно представить его ввиде таблицы с указанем планового уровня потребления в определенные периоды. На практике подобного не встречал... пока.

        P.S Календарь потребления, прикольно звучит 🙂

    2. Георгий

      Что-то не получилось с первого и второго раза опубликовать ответ 🙂 Наверное забанили 🙂 последняя попытка

      Владимир, конечно за этот показатель услуги "отвечает" процесс упр-я мощностями, но это не повод не прописывать показатель в SLA

      На моей практике, определяется согласованное целевое значение (некий "аналог" матожидания) и допустимые отклонения от него за период. Это значение + допустимые отклонения фиксируются в SLA. При существенном отклонении (минус сезонность и другие аспекты из плана мощностей) инициируется пересмотр SLA

    3. Денис Денисов Автор

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

      1. Vladimir Lyaleko

        +1 Только  в жизни хвост виляет собакой обычно именно ИТ подразделение, оценивая свои возможности, защищает себя, прописывая подобные показатели в SLA по умолчанию. О подобном документе ранее писал Евгений http://www.realitsm.ru/2012/08/default-sla/

  3. Grigory Kornilov

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

    Получаем соглашение о максимальном расширении за раз и в целом за год (<6 таких расширений), которое можно вписать в SLA.

    Полезные пороги (объем\время) поставщику и потребителю.

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

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

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

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

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