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

Чей это профиль?

Опубликовано 24 сентября 2012
Рубрики: ITIL, Вопрос из зала, Процессы
Комментарии

Заранее прошу прощения за многословность. Помогите разобраться с профилем, пожалуйста. Вдруг кто читал "Стратегию услуг"… в режиме краудсорсинга, например. 

Есть в книге Service Strategy такой процесс – управление спросом. Как и многое добавленное в ITIL в 2007 году, он не предлагает ничего принципиально нового, но добавляет деталей и красоты. Вот вкратце чем он занят:

 

Предпосылки:

    • Бизнес-процессы ведут к формированию бизнес-результатов. Для этого они используют ИТ-услуги
    • Чтобы предоставлять услуги, поставщик услуг использует ресурсы. Потребность в ресурсах определяется спросом на услуги.
    • Активность бизнес-процессов может меняться, вместе с ней – спрос на услуги.
    • Можно выявить закономерности, которым подчинены эти изменения, и использовать их для оптимизации предоставления услуг.
    • Важно обеспечить достаточную производительность ИТ-услуг с одной стороны и разумную стоимость ИТ-ресурсов – с другой.
  • Дела:
    • Анализируем бизнес-процессы и услуги, выявляем закономерности (например, сезонные колебания)
    • Документируем закономерности, результат называется Pattern of business activity (PBA), Модель бизнес-деятельности
    • Комбинируя модели, формируем User profiles (Профили потребителей). Профиль потребителя может быть связан и с одной моделью. 
    • На основе моделей бизнес-деятельности и профилей потребителей процесс управления мощностями формирует модели спроса на услуги и ресурсы. И учитывает их в плане мощностей. 

В наглядных образах это выглядит примерно так: 

Вроде всё более-менее понятно. Менее – в том, что такое User profile. И кто такие эти Users. Для начала, видимо, следует договориться, что это не конечные пользователи, нажимающие на кнопки. Странно рисовать их профили в рамках стратегического процесса. Поэтому буду называть их здесь не пользователями, а потребителями. Теперь хотелось бы понять, кто это такие в реальном мире.

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

Структуру требований к услугам и ресурсам задает модель бизнес-деятельности, индивидуальными особенностями её наполняют профили потребителей. В общих чертах вроде складывается, хотя к подробностям вопросы остаются. 

Но тут читаем в ITIL следующее: 

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

И действительно, в табличке 4.9, призванной иллюстрировать связь профилей с моделями (эту задачу табличка, на мой взгляд, не выполнила), приводятся профили следующих "users": 

  • Senior Executive
  • Highly mobile executive
  • Office-based staff
  • Payment processing system
  • Customer assistance process

Первые трое – живые люди и группы людей, предпоследняя – бизнес-система; последний – бизнес-процесс. 


Внимание, вопрос. Что они имеют в виду? Как бизнес-система может выступать в роли субъекта бизнес-процесса и потребителя ИТ-услуг? Как это же удаётся бизнес-процессу?

Кто-нибудь знает ответ или может предложить версии? 

(Убедительная просьба: версию "они курили, а мы теперь зря мучаемся" не предлагать. Она всегда есть у нас в запасе, но применять её мы договорились только когда все прочие будут отвергнуты.) 

Примечание: профиль на рисунке – известно чей. Генерала де Голля профиль, художник – Лёша Курбатов.

ITIL 4 Foundation, DSV, DPI, CDS, HVIT, DITS
и другие интересные аббревиатуры от соавторов ITIL 4

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

  • Альберт

    Если предположить что:
    Payment processing system = ERP
    Customer assistance process = CRM
    То вполне возможно, все зависит от уровня автоматизации процессов.

    • Альберт, спасибо, но все равно непонятно.

      Про систему непонятно вот что: ERP – система, за которую отвечает кто-то другой, не тот поставщик услуг, который пытается управлять спросом? Ведь если это “наша” система, ее спрос на инфраструктуру, поддержку и на что она там еще имеет спрос – дело не стратегического процесса управления спросом, а старого доброго управления мощностями. Или нет?

      Про процесс непонятно вот что: если процесс – частный случай потребителя, зачем две сущности – “PBA” и “User profile”? И так же непонятно, кто оценивает бизнес-результаты, на формирование которых процесс направлен, если потребитель – сам бизнес-процесс.

      То есть сначала выстроилась сравнительно стройная цепочка (они, кстати, так ее и называют – daisy-chain): потребители/заказчики – бизнес-процессы – ИТ-услуги – ИТ-ресурсы/способности. А потом они подставляют в начало разные звенья из середины. Зачем?

      • Альберт

        Понятие “наша” система может трактоваться довольно широко, и простого процесса управления мощностями может быть недостаточно. Для каких-то систем данный процесс не имеет смысла. Все зависит от масштабов.
        PBA – автопилот, User Profile – капитан. Результаты оценивает владелец или инвесторы. Все, в конечном счете, пересчитывается в деньги. Наверное, в двух словах не объяснить. Рекомендую: https://www-935.ibm.com/services/fr/cio/optimise/optit_wp_gts_demanddriven.pdf

        • Спасибо! ушел читать.

          • Прочитал. Спасибо, любопытно. Но ответов на свои вопросы про управление-спросом-как-оно-описано-в-itil, к сожалению, не нашел.

            • Альберт

              Другой пример:
              1. Есть поставщик, предоставляющий услуги независимым подразделениям компании по всему миру (поставщик может быть как внутренний, так и внешний).
              2. Есть надстройка управляющая услугами этого поставщика.
              3. DM – один на компанию, все аспекты глобального соглашения, выключения старых сервисов, обновление существующих, включение новых сервисов и т.д. Связан с CapM, Senior Executive компании,
              4. CapM – для каждого подразделения компании свой, все аспекты локальных соглашении (на основе глобального) объёмы услуг, стоимость, качество, заказы, оплата и т.д., связаны с DM, Senior Executive подразделения и локальными представителями поставщика.

              Далее в зависимости от масштабов и пожеланий частично могут меняться функции:
              Senior Executive подразделения меняется на Customer assistance process.
              Senior Executive компании меняется на Payment processing system.

  • Pavel Solopov

    Во-первых, есть вариант что service, process и user использованы не слишком аккуратно, и имеют разное значение даже в сравнительно небольшом отрывке текста, отсюда может возникать путаница (хотя это конечно вариант из группы “они курили”) 🙂
    Во-вторых, считаю, что Вы преждевременно отказались от вариант, что User это тот, кто нажимает на кнопки. В конце концов именно они своими нажатиями на кнопки и создают нагрузку на приложения и сервера, которые на более высоком уровне рассмотрения абстрагируются в услуги.
    Это конечно не конкретные Иванов, Петров, Сидоров, а некие обобщённые группы, ну собственно как в приведенном Вами списке и указано (Senior Executive, Highly mobile executive, Office-based staff).
    Степень нагрузки со стороны различных пользователей оперделяется той активностью, которая отведена им в рамках различных бизнес-процессов, графики их активности в различных БП (PBA) и суммируются в User profile.
    Любая смежная система это по сути тот же пользователь, она также обращается к рассматриваемой системе (услуге) и создаёт на неё нагрузку.
    Достаточно логично как мне кажется.

    Из общего ряда выбивается process, поскольку это другой уровень абстракции, в том случае если имеется в виду busines process, а не windows process например. С другой стороны группируя источники нагрузки по бизнес процессам, можно более эффективно управлять спросом, как мне кажется, нежели при группировке нагрузки по User-ам.

    • Павел, спасибо!
      Про “во-вторых”:
      всё так, конечно, но всё это описано (и было описано) в управлении мощностями. Бизнес формирует спрос на услуги, услуги – на разные уровни инфраструктуры. На каждом из этих уровней можно управлять спросом, описанный в ITIL CapM это делает.
      Для этого не нужен отдельный процесс, и тем более – на стратегическом уровне.

      Стратегическая надстройка выглядит уместной, пока она занимается стратегическими задачами. И добываемая при этом информация может влиять на портфель услуг, например. Или на модель взаиморасчетов. Или на портфель заказчиков и рынков, которым поставщик услуг адресует свои усилия. А если к стратегическим начинают относиться задачи типа “система обращается к рассматриваемой системе (услуге) и создаёт на неё нагрузку”, то либо мы очень далекий от бизнеса поставщик услуг, и наш рынок – услуги для систем, либо мы странно понимаем слово “стратегический”. IMHO, конечно.

      В книжке даже есть табличка, проводящая границу между Demand management и Capacity management. И из нее у меня получается, что DM анализирует и пытается регулировать спрос заказчиков на услуги, а CapM – планирует производительность/мощности ИТ-ресурсов так, чтобы удовлетворять этот спрос.
      В то же время в главе про CapM написано: The prime objective of demand management at the tactical level is to influence user and customer demand for IT services and manage the impact on IT resources.
      Так в чём же тогда разница между DM в SS и DM в Business Capacity Management (в SD)? Опять они путаются в показаниях…

      • Pavel Solopov

        Чем стратегия отличается от тактики? Уровнем абстракции. Управлять взводом и знать каждого бойца в лицо – тактика, а управлять армией и вообще не заботиться о том, что у тебя там какие-то люди воюют – стратегия.

        Так и здесь, вся стратегия в формировании профилей пользователей. Мы укрупнённо сформировали несколько профилей, обобщили всех пользователей и крупными мазками управляем их спросом, в этом и вся стратегия.

        А вообще мне ближе вариант “они курили” конечно. 🙂
        Или ещё вариант “им платили за количество страниц”.

  • Да мелочи жизни, просто 4тый и 5тый пункт читать как “неопределенная группа анонимных пользователей, использующих XXX – которую мы затруднились определить” и все ок. Зачем это вообще расшифровывать, ты просто единственный дочитал до 200той страницы.

  • Бизнес-система может выступать в роли субъекта бизнес-процесса и потребителя ИТ-услуг, когда рассматривается либо Вспомогательная услуга (Enabling) либо Дополняющая (Enchancing), т.е. не ориентированные на Заказчика (Customer-Facing). Для таких услуг, ведь тоже осуществляется управление спросом.

    • И да, и нет. Технически все верно, но есть у меня сомнения в том, что то управление спросом, которое описано в книге SS, занимается спомогательными услугами. Этот механизм скорее уместен в рамках тактического управления мощностями.

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

      То есть достаточно корректно определить назначение системы управления услугами – и все встает на свои места. Жаль только, что это простое, но важное замечание отсутствует в самих книжках ITIL. Или что я его там пропустил.


Добавить комментарий для Роман ЖуравлёвОтменить ответ

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM