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

Место для процесса управления изменениями

В последнее время проектная жизнь настойчиво сталкивает с процессом управления изменениями и подготовкой к его имплементации. Точно не ошибусь, если скажу, что если взять произвольную организацию в наши дни, то приложения (бизнес-критичные) в ней будут развиваться итерационным способом. Поддержка и развитие аппаратной вычислительной инфраструктуры, скорее всего, все ещё будет осуществляться проектно-водопадным способом, в силу очевидной дискретности преобразований/закупок.

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

Аналогичные мысли о месте процесса в цепочке создания ценности посещали и меня, когда я участвовал в бизнес-симуляции «Проект Феникс». Одной из действующих ролей там выступал как раз процесс управления изменения, и он ощущался весьма чуждым элементом: затратной деятельностью без  особой видимой выгоды для дела или для организации.

Казалось бы, так давайте откажемся от него?

Нет, увы. Этот процесс нам все таки будет нужен.

Назначение процесса управления изменениями состоит в том, чтобы обеспечить успешное и своевременное изменение услуг и конфигурационных единиц с наименьшим уровнем риска возникновения инцидентов. Это практически книжная формулировка.

— У нас есть команда поддержки жизненного цикла приложения, она и обеспечит минимизацию риска и своевременность доставки. Они делают это лучше всех остальных и справляются с этим сами, именно поэтому мы их и наняли, ведь так? Ага, а значит процесс управления изменениями не нужен!

— Действительно, процесс управления изменения не нужен команде для формализации преобразований внутри области ответственности команды, но он нужен вне её.

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

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

Значит процесс управления изменениями нам все таки нужен. Но какой он должен быть?

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

  1. Процесс должен работать быстро, мы не должны замедлять скорость преобразований.
  2. Процесс должен быть качественным на каждом его шаге. Мы помним, что перед нами стоят сложные кросс-системные проблемы, требующие компетенций для анализа, планирования и реализации, а также для координации всей этой кухни. Если что-то из этого будет сделано «спустя рукава», то мы не уменьшим наши риски и только потратим время впустую.
  3. Процесс должен быть строго очерчен «сверху и, особенно, снизу», мы не должны тратить ресурсы на то, что не требует этого.
  4. Процесс должен быть естественным образом встроен в коммуникации и конвейер команд, осуществляющих преобразования. Команды разные, работают с разной скоростью, используют разные инструменты и наша задача заставить их работать вместе: смотреть не только «внутрь» на свой продукт, но и «во вне», на продукты коллег, которые зависимы от них.
  5. Процесс должен быть обеспечен информацией и инструментами для оценки влияния системных преобразований. Каждый элемент инфраструктуры имеет владельца, со стороны ИТ и/или бизнеса: приложения и их модули, интерфейсы, учетные записи, оборудование, данные, наконец. Целое облако взаимосвязанных заинтересованных лиц. Ещё есть подрядчики, которые участвуют в наших цепочках оказания  услуг. Для определения реальных стейкхолдеров, связанных с преобразованием, нам будет нужна конфигурационная информация об архитектуре услуг, приложений, аппаратной инфраструктуры, взаимосвязях, интерфейсах. Без неё оценка влияния системного изменения обречена на провал.

Вот так, коллеги.

Учебные курсы и сертификация
специалистов по ИТ-менеджменту

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

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

  • Рубрики

  •  
  • Самое свежее

    • Работать меньше, чтобы сделать больше
      Все, а больше всех инвесторы и спонсоры, хотят, чтобы вся команда работала над новыми задачами, фичами, эпиками не останавливаясь. Тем не менее, несмотря на столь жгучее желание, …
    • Это же не наш профиль…
      Не смотр на то, что на нашем портале мы обсуждаем вопросы ITSM, я хотел бы затронуть тему “котиков”. Многие наверняка скажут: “Причем здесь котики? Это же не ваш профиль”. А какой …
    • Кто такие агенты изменений в продуктовой команде?
      Компании, которым жизненно необходимы частые выпуски изменений программного обеспечения, предпочитают переводить управление ИТ-разработкой в продуктовый подход. В этой статье я не …
    • Обновление Scrum Guide
      18 ноября 2020 года отцы-основатели Scrum Кен Швабер (Ken Schwaber) и Джеф Сазерлэнд (Jeff Sutherland) опубликовали новую версию руководства Scrum (Scrum Guide). Это особенно …
    • Где в ITIL можно почитать про управление техническим долгом?
      Во время вебинара нам поступил вопрос: Есть ли в практиках ITIL разделы\главы, в которых уделяется внимание управлению техдолга? (чтобы почитать)…
    • Технический долг: как бороться с невидимым врагом
      Зачастую о техническом долге говорят, как о плохо сделанной работе. Но брак есть брак, он порождает отходы, а не долги. А технический долг может накапливаться незаметно и …
    • Он и тебя посчитал
      В своей недавней заметке Олег Скрынник начал диалог на тему диагностики продуктовых команд, как потока. Думая о теме со своей стороны, больше с ракурса уютной внутрикомандной …
    • «DevOps Handboek» — «DevOps для ИТ-менеджеров» на голландском
      Книга Олега Скрынника «DevOps для ИТ-менеджеров» — лучший выбор для тех, кто хочет разобраться в том, что такое DevOps, — вышла на голландском …
    • Диагностика продуктовых команд как поток
      Представим, что у нас есть продуктовая команда. Ну или группа людей, которые очень хотели бы таковой стать. Ну или мы хотим, чтобы они стали — не суть. Предположим, что …
    • Учёт доступности? А можно как-то попроще?
      На днях, когда я в очередной раз рассказывал про управление доступностью на курсе ITIL PPO, мне задали такой вопрос: «а можно как-то попроще?». Вопрос, в общем-то, …
  •  
  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT