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

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

Есть в книге 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

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


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

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

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

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

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

ITIL ITIL Practitioner — новый учебный курс 2016

Правильный следующий шаг после ITIL Foundation.
 

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

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

    1. Роман Журавлёв Автор

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

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

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

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

      0
      0
      1. Альберт

        Понятие «наша» система может трактоваться довольно широко, и простого процесса управления мощностями может быть недостаточно. Для каких-то систем данный процесс не имеет смысла. Все зависит от масштабов.

        PBA — автопилот, User Profile — капитан. Результаты оценивает владелец или инвесторы. Все, в конечном счете, пересчитывается в деньги. Наверное, в двух словах не объяснить. Рекомендую: www-935.ibm.com/services/...demanddriven.pdf

        0
        0
            1. Альберт

              Другой пример:

              1. Есть поставщик, предоставляющий услуги независимым подразделениям компании по всему миру (поставщик может быть как внутренний, так и внешний).

              2. Есть надстройка управляющая услугами этого поставщика.

              3. DM — один на компанию, все аспекты глобального соглашения, выключения старых сервисов, обновление существующих, включение новых сервисов и т.д. Связан с CapM, Senior Executive компании,

              4. CapM — для каждого подразделения компании свой, все аспекты локальных соглашении (на основе глобального) объёмы услуг, стоимость, качество, заказы, оплата и т.д., связаны с DM, Senior Executive подразделения и локальными представителями поставщика.

              Далее в зависимости от масштабов и пожеланий частично могут меняться функции:

              Senior Executive подразделения меняется на Customer assistance process.

              Senior Executive компании меняется на Payment processing system.

              0
              0
  1. Pavel Solopov

    Во-первых, есть вариант что service, process и user использованы не слишком аккуратно, и имеют разное значение даже в сравнительно небольшом отрывке текста, отсюда может возникать путаница (хотя это конечно вариант из группы «они курили») 🙂

    Во-вторых, считаю, что Вы преждевременно отказались от вариант, что User это тот, кто нажимает на кнопки. В конце концов именно они своими нажатиями на кнопки и создают нагрузку на приложения и сервера, которые на более высоком уровне рассмотрения абстрагируются в услуги.

    Это конечно не конкретные Иванов, Петров, Сидоров, а некие обобщённые группы, ну собственно как в приведенном Вами списке и указано (Senior Executive, Highly mobile executive, Office-based staff).

    Степень нагрузки со стороны различных пользователей оперделяется той активностью, которая отведена им в рамках различных бизнес-процессов, графики их активности в различных БП (PBA) и суммируются в User profile.

    Любая смежная система это по сути тот же пользователь, она также обращается к рассматриваемой системе (услуге) и создаёт на неё нагрузку.

    Достаточно логично как мне кажется.

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

    0
    0
    1. Роман Журавлёв Автор

      Павел, спасибо!

      Про «во-вторых»:

      всё так, конечно, но всё это описано (и было описано) в управлении мощностями. Бизнес формирует спрос на услуги, услуги — на разные уровни инфраструктуры. На каждом из этих уровней можно управлять спросом, описанный в 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)? Опять они путаются в показаниях...

      0
      0
      1. Pavel Solopov

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

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

        А вообще мне ближе вариант «они курили» конечно. 🙂

        Или ещё вариант «им платили за количество страниц».

        0
        0
  2. Александр Жилинский

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

    0
    0
  3. Oleksandr Vinnytskyi

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

    0
    0
    1. Роман Журавлёв Автор

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

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

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

      0
      0

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

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

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

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

ОКТ
23