Управление мощностями и способ идентификации ИТ-услуг

Разбираясь с методическими вопросами сервисно-ресурсного планирования, я решил рискнуть и немного поспорить с авторами ITIL. На этот раз о том, как устроен процесс управления мощностями (Capacity management).

Авторы ITIL выделяют в управлении мощностями три подпроцесса:

  • Business Capacity Management
  • Service Capacity Management
  • Resource Capacity Management

Думаю, я с таким делением не совсем согласен 🙂

UPDATED: Согласен. См. https://realitsm.ru/2014/03/cap-mgmt-and-service-identification/#comment-26520

confusion

Попробую обосновать. Представим себе три наиболее распространенных варианта ИТ-услуги (список таких вариантов не полон, более целостное изложение представлено в вебинаре Дениса Денисова «Формируем каталог ИТ-услуг: бизнес-процессы, ИТ-системы или функции?»):

  1. ИТ-услуга – предоставление ресурса (каналов, вычислительных мощностей, хранилищ и так далее);
  2. ИТ-услуга – обеспечение работоспособности информационных систем;
  3. ИТ-услуга – ИТ-обеспечение исполнения и развития бизнес-процессов.

Вспомним, что каталог услуг по своей сути является инструментом коммуникаций. То есть услуга это фактически именно то, что является предметом диалога между поставщиком (ИТ-подразделением) и потребителем.

А теперь рассмотрим эти случаи более подробно.

1. ИТ-услуга как предоставление ресурса

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

Три подпроцесса управления мощностями в этом случае сокращаются до одного – Resource Capacity Management. Этот же подпроцесс можно называть Service Capacity Management, ведь услуга ассоциируется именно с ресурсом.

2. ИТ-услуга как обеспечение работоспособности ИТ-системы

Наш потребитель говорит на языке систем – какими пользуется, к каким необходим доступ, какие нужны характеристики скорости, надежности и так далее. Это довольно распространенный вариант отношений между ИТ-подразделением и другими подразделениями в пределах одной компании. Такой же диалог характерен для сценария SaaS.

Три подпроцесса управления мощностями в этом случае сокращаются до двух – Service Capacity Management (какие мощности нужны потребителю) и Resource Capacity Management (какие мощности для этого необходимо обеспечить на уровне ресурсов). При этом название Service Capacity Management можно заменить на System Capacity Management, ведь услуга связана именно с ИТ-системой.

3. ИТ-услуга как обеспечение исполнения и развития бизнес-процесса

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

Вот теперь (и только теперь) нужны все три подпроцесса. Но название Service Capacity Management нужно заменить на System Capacity Management, ведь услуга – это уже не про систему, а про бизнес-процесс.

Выводы

Следовательно, на основании предыдущих рассуждений, в процессе управления мощностями можно выделить три подпроцесса:

  • Business Capacity Management
  • System Capacity Management
  • Resource Capacity Management

и сформулировать следующие границы их применения:

cap

При этом термин Service Capacity Management как фиксированное название подпроцесса лучше не использовать, поскольку, в зависимости от того, как выделены наши услуги, деятельность по управлению мощностями услуг может "располагаться" на любом из уровней: Business, System или Resource Capacity Management.

Крамола? Но где я не прав?

UPDATED: https://realitsm.ru/2014/03/cap-mgmt-and-service-identification/#comment-26520

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

ITIL ITIL Intermediate: Planning Protection and Optimization

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

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

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

  1. Константин Нарыжный

    Есть еще, между прочим, статья Романа с похожей классификацией.

    Мне кажется, что авторы ITIL выделили эти три подпроцесса, исходя как раз из того, что заказчик в принципе не говорит с вами ни на каком из предложенных языков. Это вам нужно с ним разговаривать. Поэтому даже в случаях 1 и 2, business capacity management нужен.

    1. Дмитрий Исайченко Автор

      Это вам нужно с ним разговаривать.

      Согласен.

      Поэтому даже в случаях 1 и 2, business capacity management нужен.

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

      1. Константин Нарыжный

        Вот про услугу-ресурс. Представьте, что вы решаете, сколько у вас будет в парке ПК на аренду в новом году. Два уровне прогнозирования же: 

        1. нужно спрогнозировать динамику самих ресурсов (т.е. посчитать сколько их всего средний срок службы экстраполировать, прочитать отчёт о том, сколько ПК находится в долгосрочном лизинге и т.д.), чтобы решить сколько вам потребуется, чтобы поддержать текущий уровень предложения.

        2. нужно спрогнозировать динамику спроса: а не случится ли в мире новой глобальной моды на ноутбуки chromium? каким будет спрос на ваши услуги аренды ПК?

        А в "реактивной" части выглядеть будет так: на уровне "1" вы будете мониторить все ПК (работает\не работает, в аренде\на складе), а на уровне "2" вы будете мониторить стоимость продаваемых, заключенных, оплаченных контрактов на аренду. 

        Делать это будут разные люди, с разной периодичностью, с разными выходами. Поэтому и два процесса, кмк.

        1. Дмитрий Исайченко Автор

          Да, такое деление также возможно. Если я правильно понял, Business Capacity Management — это больше про бизнес поставщика услуг, да? Т.е. Business Capacity Management (BCM) — мы думаем, как масштабировать наш бизнес, Service Capacity Management (SCM) — как это ложится на отдельные услуги, Resource Capacity Management (RCM) — какие внутренние ресурсы нам для этого нужны?

          1. Константин Нарыжный

            Если я правильно понял, Business Capacity Management — это больше про бизнес поставщика услуг, да?

            Нет, я имел в виду бизнес заказчика. В примере с арендой ПК — это  деятельность тех, кто арендует ПК. В книжках то же самое. Они вообще в книжке про проектирование услуг говорят проще: BCM — это анализ моделей бизнес-деятельности (PBA), то есть понимание динамики спроса на ИТ-услуги, например, сезонных вариаций А я выше написал о том, что эти вариации могут быть и нецикличными. Но в любом случае от имеющихся у поставщика услуг ресурсов\систем\услуг эта динамика не зависит. 

            Это отдельная тема (пассивный анализ спроса + активное стимулирование спроса),  которая в ITIL немного запутана между тремя процессами. Но если мы строим реалистичную модель, то Demand Management и Business Relationship Management в ней присутствовать вряд ли будут.  Business Capacity Management как подвид управления мощностями — самый простой ответ 😉

            1. Дмитрий Исайченко Автор

              Они вообще в книжке про проектирование услуг говорят проще: BCM — это анализ моделей бизнес-деятельности (PBA), то есть понимание динамики спроса на ИТ-услуги, например, сезонных

              Да, я помню. Именно поэтому я и писал про планирование своего бизнеса, а не бизнеса заказчика. Смотрите сами: если BCM — это анализ спроса на услуги, которые мы оказываем, и вытекающее из этого планирования объемов оказания услуг, то в коммерческом поставщике BCM по сути - работа ПЭО. Именно поэтому и отделяется BCM от SCM: BCM — бизнес-планирование (делают экономисты), SCM — планирование реализации на основае бизнес-планов (делают предметники). Тут все ОК, только немного непривычно применять к этой деятельноси название BCM. А в корпоративном (некоммерческом поставщике) отделять это от SCM уже кажется не очень нужно, если только в составе ИТ-подразделения нет своего ПЭО.

              То есть при таком выделении подпроцессов BCM появляется только там, где оказание ИТ-услуг — это бизнес.

              1. Дмитрий Исайченко Автор

                То есть при таком выделении подпроцессов BCM появляется только там, где оказание ИТ-услуг — это бизнес.

                А SCM отделяется от RCM там, где услуга — это не просто предоставление ресурса (иначе опять есть совпападение исполнителей и предметной области, то есть рациональность выделения самостоятельных подпроцессов вызывает вопрос).

                1. Дмитрий Исайченко Автор

                  Вообще, Костя, оргомное спасибо. Это очень важное уточнение.

                  BCM отделяется там, где предоставление ИТ-услуг — это бизнес. SCM от RCM отделяется там, где услуга — это больше, чем ресурс, предоставляемый потребителю. А это по идее должно быть всегда. Ведь, помимо ресурсов, всегда есть деятельность, как минимум по поддержке потребителей. Всегда есть внутренние обеспечивающие ресурсы (не те, которые заказывает потребитель). И это, кстати, очень бьется с eTOM, согласно которому услуга может быть только деятельностью или комбинацией ресурсов и деятельности, но никогда не только ресурсом.

                  Т.е. фокус BCM — бизнес-планирование поставщика ИТ-услуг, фокус SCM — потребности заказчика услуги, фокус RCM — ресурсы для обеспечения потребностей заказчика. Все разумно.

                  При этом введение уровня System Capacity Management может быть спорно именно потому, что система сама по себе может рассматриваться просто как сложный, составной ресурс. Ведь отдельные ресурсы, используемые системой, на очередном уровне детализации могут быть представлены самостоятельными системами.

                  Костя, спасибо! Распутали.

                  1. Константин Нарыжный

                    Полуается, что BCM отделяется там, где предоставление ИТ-услуг — это бизнес.

                    Точно так. Вы будете смеяться, но ITSM из предпосылки "ИТ-организация — это бизнес" весь и вырос чуть более, чем полностью =)

                    Т.е. фокус BCM — бизнес-планирование, фокус SCM — организационое планирование, фокус RCM — техническое планирование. Это разумно.

                    Во! отлично! вот это и задело с системами-то... Наш диалог напомнил сегодня классическую картинку 😉

                    Оффтоп: английский язык в ITIL 2011 гораздо легче, плавнее, живее, чем в любом другом известном мне аналоге, включая учебники по менеджменту. Я всем и всегда желаю найти в жизни двое суток и сколько-то там фунтов стерлингов и прочитать Service Strategy 2011, хотя бы раздел 3 и веселый 4.2.5.18, например. Гарантирую: о-очень многое станет понятнее.

                    1. Дмитрий Исайченко Автор

                      Точно так. Вы будете смеяться, но ITSM из предпосылки "ИТ-организация — это бизнес" весь и вырос чуть более, чем полностью =)

                      Нет, не буду. Это понятно и много раз говорено.

                    2. Павел Солопов

                      Вы будете смеяться, но ITSM из предпосылки "ИТ-организация — это бизнес" весь и вырос чуть более, чем полностью =)

                      Скорее из предложения рассматривать ИТ в организации, как независимый бизнес. Но это тонкости философского ряда. 🙂

                  2. Георгий

                    Я бы тоже оставил все три уровня как и есть в книжках.

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

                    S (ervice) CM — нужен везде, так как управляем мы всё же сервисами, а сервис не равен ресурсу, как ты очень верно подметил

                    Про RCM, я так понял, и изначально сомнений не было 🙂

              2. Павел Солопов

                BCM — бизнес-планирование (делают экономисты), SCM — планирование реализации на основае бизнес-планов (делают предметники)

                А что менеджмент уже сводится только к планированию? Как то это узко. Т.е. раньше просто выполняли планирование на следующий год, а теперь управляем мощностями бизнеса (хотя делаем всё тоже планирование)...

                1. Дмитрий Исайченко Автор

                  С моей точки зрения Capacirty Management (CM) — это не только процесс, а комбинация процесса и функции. Например, я бы точно не стал делать устранение и расследование инцидентов, связанных с мощностями, частью процесса управления мощностями. На это есть управление инцидентами и проблемами соответственно. А вот участие в устранении и расследовании вполне могут принимать специалисты, выполняющие функцию CM.

                  Теперь посмотрим сверху: управление = целепостановка + планирование + организация выполнения + контроль и анализ (иногда, говоря про менеджмент, явно выделяют еще мотивацию, но, обобщая, вполне можно считать мотивацию составной частью организации выполнения). ИМХО, из представленных четырех составляющих именно планирование наиболее адекватно ложится в процессную часть CM, а остальное — в функциональную (поскольку процессно "разваливается" на CHG, EVT, INC, PRB, ...). Поэтому, наверно, и происходит такое сужение в разговоре.

  2. Vadim Tomkevich

    Привет Дмитрий,

    По-моему в " Но название Service Capacity Management нужно заменить на System Capacity Management, ведь услуга – это уже не про систему, а про бизнес-процесс. " есть опечатка в части на что менять, должно быть где-то Process, Service, Business, наверно любой из вариантов в зависимости от того что поддерживаем сверх ресурсов и систем. Ну или я не совсем уловил суть...

    В целом мне кажется что было бы неплохо чтобы названия типов услуг и подпроцессов пересекались минимально — иначе очень "конфузит" на первый взгляд.

  3. Павел Солопов

    А я бы предложил другой взгляд:

    BCM — должен обеспечить желаемый уровень производительности бизнеса, т.е. чтобы производилось то количество услуг или товаров, которое по каким-то соображениям признано необходим. BCM выполняется на стороне бизнеса, причём под бизнесом понимается, как основное производство компании, если ИТ внутренне, так и бизнес компании заказчика, если ИТ — коммерческая компания.

    BCM определяет требования к производительности ИТ-сервисов, за обеспечение производительности в соовтетствии с этими требованиями отвечает SCM. SCM реализуется на стыке ИТ и его заказчика (внутреннего или внешнего).

    SCM определяет требования к производительнсоти компонентов, из которых состоят сервисы. А за обеспечение заданной производительности этих компонентов отвечает RCM. RCM реализуется внутри ИТ.

  4. 35 stupenek

    Управление мощностями принимает во внимание все ресурсы, необходимые для предоставления услуг, а также производит краткосрочное, среднесрочное и долгосрочное планирование бизнес-требований.

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

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

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

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

АВГ
28