Процессы верхнего уровня: руки или мозг?

Коллеги, который раз сталкиваюсь с необходимостью проектирования процессов "верхнего уровня" (иногда их называют тактическими процессами): управление мощностями, доступностью и т.д.  Занятие это весьма интересное и сильно зависящее от конкретной ситуации в компании. Мне видится два подхода:

  • Сделать процесс в рамках которого осуществляются все активности связанные с соответствующими параметрами ИТ-услуг.

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

Нажмите для увеличения

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

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

Нажмите для увеличения

Мне кажется, что оба подхода имеют право на жизнь, каждый со своими плюсами и минусами. 

ITIL ITIL Intermediate: Service Offerings and Agreements

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

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

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

      1. Олег Скрынник

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

        А вместо плюсов-минусов можно рассмотреть границы применимости. Например, если организация в ближайшие годы собирается освоить пару-тройку операционных процессов и вдруг дойти до одного-двух тактических (простите за терминологию из ITIL v2), то первый вариант будет предпочтительнее. И крыша сразу не уедет, и сложной картины строить не нужно.

        Если же сразу думать про систему из десятка и более процессов, то второй вариант даёт больше преимуществ. В первую очередь — по ресурсам, задействованным в процессах. Во вторую — в ясности взаимодействия между процессами, и ясных временных точках взаимодействия.

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

    Моё мнение: управление мощностями и доступностью — это то, что ITILv3 называет словом Capability. И прежде всего эта Capability будет иметь форму функций (которые, в том числе, привлекаются операционными процессами — при оценке изменений и так далее). В некоторых организациях (при осознании потребности) могут быть формализованы ещё и процессы CAP/AVM, которые по своей сути организуют цикл PDCA над операционной деятельностью в части решения вопросов мощностей и доступности.

    То есть получается, что я больше за второй вариант. В первом меня смущает обилие операционных взаимосвязей между процессами, что приводит:

    1. к размыванию ответственности и усложнению контроля;

    2. к смешиванию в рамках процессов CAP/AVM активностей разного уровня управления (операционного и тактического), что усложняет понимание процесса исполнителями;

    3. и, как следствие 1 и 2, повышает риски нарушения процессов и снижает их эффективность.

    1. Евгений Шилов Автор

      Дима, спорные утверждения:

      1. «к размыванию ответственности и усложнению контроля» Мне кажется как раз наоборот, повышается вероятность того, что внедряемое решение пройдет проверку/проработку по всем значимым характеристикам. Т.к. например, люди осуществляющие разработку заинтересованы в скорейшей реализации, а не в детальной проработке вопросов доступности. Так же как и люди осуществляющие внедрение. А расхлебывать потом людям, которые потом займутся эксплуатацией получившегося решения.

      2. «к смешиванию...» — зависит от ролевой модели, тактическими вопросами могут заниматься одни люди, а операционные решать другие. При этом все могут прекрасно понимать что и зачем они делают.

      1. Олег Скрынник

        Я вот тоже не очень понял почему у первого варианта возникает смешивание активностей, а у второго — нет.

        Можно ведь для простоты картины считать «верхние» процессы тактическими, убирая из них по максимуму оперативную часть. Грубо говоря, пусть в предельном случае управление мощностями раз в год выдаёт план мощностей, аккурат к бюджетному циклу. А мониторинги и прочие оперативные процедуры отрабатывают те, кто «внизу» — в рамках процессов или ещё как, неважно.

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

    Евгений, мне кажется, не хватает земных примеров для этих вариантов.

    Я слабо себе представляю второй вариант. Это получается, сидят умные дяденьки и готовят требования ко всем остальным дяденькам. А к кому именно — сами еще, может, и не знают.

    Менеджер по мощностям (читай — архитектор ИС) знает о том, как происходят релизы в продуктив и поддержка пользователей?

    1. Евгений Шилов Автор

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

    2. Олег Скрынник

      Возьмём управление инцидентами. Суть процесса не в том, чтобы менеджер инцидентов решал инциденты, а чтобы он организовал работу по решению инцидентов. Сам он при этом может иметь весьма поверхностное знание MS SQL и прочих СКС с телефонией и SAP. Итого: процесс управления инцидентами является управляющим по отношению к деятельности людей с отвёртками, чтобы они не просто бегали, а с пользой в отдельно взятой области — устранения инцидентов.

      Теперь берём управление доступностью. В первом случае, приведённом в заметке Жени, процесс будет управляющим по отношению к деятельности любого айтишника, влияющего на доступность. Во втором — по отношению к процессам жизненного цикла, если таковые выделены и организованы. В любом из двух случаев менеджер управления доступностью также может не быть в курсе технических деталей разных частей инфраструктуры. Его задача — организовать деятельность других так, чтобы с доступностью всё было в порядке. Чтобы про неё не забывали при проектировании, тестировании, внедрении, эксплуатации.

      Оба варианта имеют право на жизнь, разве нет?

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

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

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

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

МАЙ
2
Учебный курс:
Основы ITIL (очно)
МАЙ
15