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

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

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

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

 

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

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

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

 

 

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

  • Альберт

    Чаще всего работает такая модель:
    Внутренний заказчик – услуга <= стоимость – ИТ Бюджет – стоимость <= услуга – Внешний поставщик
    В случаи с внутренним заказчиком оговаривается максимальный объем услуг, в случаи с внешним поставщиком чаще оговаривается минимальный объем услуг. На эти 2% мы и живем 🙂

  • Vladimir Lyaleko

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

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

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

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

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

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

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

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

     

    • Георгий

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

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

      • Vladimir Lyaleko

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

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

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

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

    • Георгий

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

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

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

      • Георгий, нет, ни в коем случае не забанили. Что-то произошло с комментариями к посту. Они немного "замёрзли" в ожидании.

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

      • Vladimir Lyaleko

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

        • Да, но, на мой взгляд, это предложенную картину не меняет: подмножества default_sla и custom_sla (назовём так?) составляют множество _sla, и из них верстается План.

           

  • Grigory Kornilov

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

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

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


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM