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

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

Опубликовано 22 сентября 2011
Рубрики: ITIL, ITSM, SLA, SLM, BRM, Обо всём на свете
Комментарии

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

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

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

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

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

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

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

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

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

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

  • Думаю, что вывод корректный — оба подхода имеют право на жизнь.

    Вопрос к докладчику — нужно покритиковать? предложить третий вариант? рассмотреть плюсы/минусы?

    • По всем трем вопросам — ДА. 🙂 Было бы интересно услышать ваше мнение по каждому из вариантов. Если есть третий, то с удовольствием готов обсудить.

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Классные темы пошли: «крылья, ноги и хвосты», «руки или мозг» 😀

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

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

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

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

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

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

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


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

Ваш адрес email не будет опубликован.

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM