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

Разбираемся с управлением спросом: процесс

service_beltВ последнее время мне доводится много проводить учебный курс "Экономика и финансы ИТ", одним из разделов которого является управление спросом (Demand Management). С одной стороны, тема совершенно теоретическая. В ITIL есть книжка, в ней целый раздел, на экзамене могут быть по нему вопросы – надо разбираться. С другой, всё больше и больше наших клиентов консалтинговых услуг ставят задачи из реальной жизни, так или иначе связанные с тем самым управлением спросом. Это только на первый взгляд кажется, что между операционным бюджетом ИТ, расчётом численности ИТ-персонала и обоснованием инвестиций в ИТ нет ярких связей. Есть, конечно же. Спрос на услуги и ресурсы.

the-aha-momentДмитрий Исайченко, когда разбирается с какой-либо темой, в определённый момент заявляет: "Я всё понял!". Как правило, это означает, что он готов перечислить коротким списком из трёх-пяти пунктов суть выполняемой деятельности; ключевые выходы, а также когда, кем и зачем они используются; основные входы. Любые проверочные и уточняющие вопросы находят чёткие ответы в данной картине.

К сожалению, в книге "Service Strategy" информации об управлении спросом, скажем так, немного. Только самое необходимое.

К счастью, сама тема довольно хорошо проработана, и информацию можно найти в бизнес-литературе. Особенно в разделах "Маркетинг" и "Управление цепочками поставок".

Я сделал первый подход к снаряду – на основе прочитанного и продуманного набросал схему основных сущностей и связей процесса управления спросом. У меня получилась такая схема:

demand_management

(на картинку можно и нужно нажать).

До состояния "я всё понял" пока далековато, но основные моменты вырисовываются такие.

Во-первых, управление спросом не работает в изоляции. Граница между Service Portfolio Management и Demand Management напоминает проблему курицы и яйца, но совершенно понятно, что на каком-то этапе их взаимодействия появятся изменения в портфеле услуг. А это – важный вход для первой процедуры управления спросом, Influence. Нам надо уметь (или учиться) влиять на спрос. На основе стратегии и заданных целей, а также с учётом ограничений наших сервисных активов мы и оказываем влияние на спрос – с помощью инструментов маркетинга, в частности – цен на наши услуги.

Вторая процедура – оценка, Assess. Одновременно с пониманием нашего возможного влияния на спрос мы можем (и должны) оценить спрос на услуги, для чего за основу берём наше понимание рынка и клиентов, а также статистику прошлых продаж. Во всех нужных нам разрезах. Получается две активности: оценка смотрит "как было", влияние предполагает "как может быть".

Самое время перейти к третьей процедуре – прогнозирования, Forecast. Именно она и создаёт то полезное, что является выходом управления спросом – чёткие, понятные и количественно выраженные требования к предоставляемым нами услугам. Побочными, но важными результатами этой процедуры являются модели бизнес-деятельности (PBA, Pattern of Business Activity) и профили пользователей (User Profiles). Эти штуки как раз хорошо описаны в ITIL 2011.

Результаты же передаются в управление мощностями, Capacity Management, где на их основе создаётся план мощностей. Нам ведь нужно, чтобы наши активы (ресурсы) приносили отдачу, чтобы их было не меньше и не больше, чем требуется. Транслировать требования услуг в требования к ресурсам – как раз задача управления мощностями.

Следующим шагом – детализация процедур, изучение применимых к их работе инструментов и методик, проверка полноты картины. Следите за публикациями, делитесь идеями, комментируйте! Буду рад обратной связи, так как Visio со мной разговаривать не хочет.

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

  • Антон Лыков

    Олег, в целях благозвучности предлагаю слово asses (коротое на самом деле пишется как assess), заменить на estimate или evaluate. Иначе получается какая-то… ерунда.

    А по сути да, похоже на правду. Я тоже примерно так понимал.

    Важный и сложный момент тут, что спрос (demand) – это не только "когда, сколько и с каким качеством", но и "что" (какие услуги). Потому что из частого упоминания связи с capacity management в книжке можно сделать вывод, что это такая "стратегическая часть capacity".

    • Антон, спасибо. Опечатку, конечно, надо поправить, а то какой-то второй смысл появляется у процедуры 🙂

  • Александр Васильев

    Про курицу/яйцо – насколько надо разделять Service Portfolio Management и Demand Management? Их задачи настолько переплетаются, что я не понимаю вовсе смысла разделения.

    • Видимо, это зависит от взгляда смотрящего. Например, тов. Филип Котлер объединил бы не Demand Management и Service Portfolio Management, а включил бы управление спросом в маркетинг.

  • Все же жаль, что PBA, User profiles и Service requirements являются выходами из Forecast. По смыслу должен быть какой-то Analysis, который предшествует Forecast. Да и в жизни, как мне кажется, происходит именно так. А может быть, это вообще логично считать частью SPM?

    • В моём понимании анализ – часть Forecast, "предсказания". Прогнозирование без анализа не сделать, а выделять процедуру (или шаг) анализа отдельно я пока не понимаю зачем.

       

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

        • Похоже, работа с PBA (с точки зрения ITIL) размазана между Demand и Capacity. Создание и первичный анализ с точки зрения бизнеса – в Demand, а наложение на услуги и ресурсы – в Capacity. Примерно так:

          These new requirements may come to the attention of capacity management from many different sources and for many different reasons, but the principal sources of supply should be the patterns of business activity from demand management. The demand management process will analyse patterns of business activity to find out how these patterns generate demand patterns for IT service and, together with service portfolio management, will create service packages and service options at the right level of utility and warranty to efficiently support these patterns

          • А ты как считаешь, это размазывание – сознательное или так получилось (разные люди писали разные книжки)?

            • Как раз об этом думал. В данном случае мне кажется, что это несогласованность авторов. Дэвид Кэннон чётко обозначает в Service Strategy место и роль Demand, а также отличия от Capacity. Это хорошо бьётся с тем, что я читаю/читал про Demand Management в бизнесе.

              А авторы Service Design всячески завышают роль Capacity, возвращая идеи ITIL v2 про три уровня процесса и т.д. Что не очень согласуется с текстом Service Strategy.

              C другой стороны, можно рассуждать и иначе. Текст Service Strategy по данному вопросу ближе к внешним провайдерам, у них своя сервисная экономика и свои акценты в Demand. А текст в Service Design ближе к внутренним провайдерам. Вот картинка и складывается 🙂

              • Вот картинка и складывается

                Ну, у меня пока не очень. Я так понимаю, что Demand management (DM) в ITIL – это замена Business capacity management'у (BCM). Причем если BCM только про необходимые мощности, то DM – и про новые услуги, и про изменения существующих. Вот если BCM из Service Design убрать и сослаться на DM, тогда да, сложится.


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM