Разбираясь с методическими вопросами сервисно-ресурсного планирования, я решил рискнуть и немного поспорить с авторами 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
Попробую обосновать. Представим себе три наиболее распространенных варианта ИТ-услуги (список таких вариантов не полон, более целостное изложение представлено в вебинаре Дениса Денисова «Формируем каталог ИТ-услуг: бизнес-процессы, ИТ-системы или функции?»):
- ИТ-услуга – предоставление ресурса (каналов, вычислительных мощностей, хранилищ и так далее);
- ИТ-услуга – обеспечение работоспособности информационных систем;
- ИТ-услуга – ИТ-обеспечение исполнения и развития бизнес-процессов.
Вспомним, что каталог услуг по своей сути является инструментом коммуникаций. То есть услуга это фактически именно то, что является предметом диалога между поставщиком (ИТ-подразделением) и потребителем.
А теперь рассмотрим эти случаи более подробно.
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
и сформулировать следующие границы их применения:
При этом термин Service Capacity Management как фиксированное название подпроцесса лучше не использовать, поскольку, в зависимости от того, как выделены наши услуги, деятельность по управлению мощностями услуг может "располагаться" на любом из уровней: Business, System или Resource Capacity Management.
Крамола? Но где я не прав?
UPDATED: https://realitsm.ru/2014/03/cap-mgmt-and-service-identification/#comment-26520
Есть еще, между прочим, статья Романа с похожей классификацией.
Мне кажется, что авторы ITIL выделили эти три подпроцесса, исходя как раз из того, что заказчик в принципе не говорит с вами ни на каком из предложенных языков. Это вам нужно с ним разговаривать. Поэтому даже в случаях 1 и 2, business capacity management нужен.