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

Четыре мысли про управление изменениями

Опубликовано 24 октября 2011
Рубрики: ITIL, Обо всём на свете, Управление изменениями
Комментарии

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

Мысль первая – процесс управления изменениями на начальном этапе может внедряться даже как простой способ обновления CMDB и не более. Т.е. ту часть цели, которая касается снижения негативного влияния изменений можно оставить в стороне на некоторое время. И только после того как удастся добиться стабильной работы процесса в части единообразного проведения изменений, можно будет сосредоточиться и на снижении влияния. К слову сказать, даже просто единообразие отчасти повлияет улучшение ситуации со снижением влияния.

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

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

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

Мыслей по этому поводу конечно же еще вагон. Но с этих, мне кажется, стоит начать. Если не согласны, то готов обсуждать.

ИНТЕНСИВ С ТРЕНЕРОМ
VAP: Управление изменениями и конфигурациями в ИТ
Повысить долю успешных изменений, снизить риски, знать всё про конфигурации

Также по теме:

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

  • Leonid

    «Если не согласны, то готов обсуждать.»
    Не то чтобы совсем не согласны, но обсудить стоит, тема интересная.

    «Мысль первая…» Практика показывает, что ведение CMDB является как раз самой трудоемкой частью связки изменения+конфигурация, так как к внедрению этих процессов деятельность по реализации изменений уже, как правило, упорядочена и регистрируется в виде заданий, работ и т.п. Кроме того, процесс изменений нужен хотя бы как вход в конфигурации. Так что предлагаемая экономия кажется не слишком полезной, скорее наоборот, больше потеряем на переделках и переучивании.
    «Мысль вторая…» Теоретически все верно, однако, например, в текущем проекте неожиданно выяснилось, что те регламенты стандартных изменений, которые координаторы изменений сами же для себя и разработали, в реальной практике неприменимы, а используются лишь фиктивно, для улучшения отчетности. Теперь координаторы утверждают, что у них не может быть и двух одинаковых изменений.
    «Мысль третья…» Конечно, формализация деятельности уже сама по себе способствует снижению числа ошибок. Но вот как определить, насколько процесс управления изменениями достигает своей цели, не очень понятно. Хотелось бы примеры метрик.
    «Мысль четвертая..» Немного противоречит мысли первой, но лозунг красивый.

    • Евгений Шилов

      Леонид, давайте по-порядку:
      1. Если деятельность по реализации изменений уже упорядочена, то конечно одной из задач будет интеграция с процессом управления конфигурациями, я не предлагаю делать шаг назад. Не буду спорить о том, как это бывает на практике, т.к. она бывает разной, но мне пока больше попадались ситуации, когда работающего ПРОЦЕССА управления изменениями нет.
      2. Пополнение классификатора, в том числе, стандартными изменениями – серьезная работа, которая требует, в том числе, работы менеджера процесса. Если стандартное изменение фиктивно, и не несет пользы с точки зрения процесса, то зачем ему быть в классификаторе.
      3. Мы уже как-то обсуждали этот вопрос. Действительно, оценка эффективности процесса – непростое дело.
      4. А в чем Вы видите противоречие?

      • Leonid

        1. Как Вы совершенно справедливо заметили: практика бывает разной, мне вот всегда попадалась более-менее упорядоченная деятельность по реализации изменений при гораздо худшей деятельности по управлению конфигурации, ну это кому как везет.

        2. «Если стандартное изменение фиктивно, и не несет пользы с точки зрения процесса, то зачем ему быть в классификаторе». Так это ж элементарная физика;)! Под воздействием силы лени, тело стремиться вернуться в состояние покоя. Поэтому приходится прикладывать некую силу – мотивацию, превышающую силу лени. Но так как «оценка эффективности процесса — непростое дело», соответственно и с метриками у нас беда, то и вектор силы мотивации у нас направлен черт знает куда. И при наложении еще и силы лени, стремящейся вернуть тело в состояние покоя кратчайшим путем, получаем от участника процесса не совсем те действия, какие от них ожидали.

        3. «Мы уже как-то обсуждали этот вопрос. Действительно, оценка эффективности процесса — непростое дело». Обсуждали, дело не простое. Но вы предлагаете на основе этой оценки принимать принципиальные решения, вот я и подумал, вдруг у Вас уже есть конкретные решения проблемы.

        4. «А в чем Вы видите противоречие?»
        «процесс управления изменениями на начальном этапе может внедряться даже как простой способ обновления CMDB и не более».
        «процесс управления изменениями необходимо сразу проектировать с расчетом на снижение негативного влияния». Дальше, правда, идет уточнение «а вот запускать стоит постепенно, вводя новые требования и расширяя охват процесса и функциональность процедур в рамках процесса, по мере освоения предыдущих», но в комментарии к первой мысли я уже выразил свое сомнение в полезности отрезания хвоста по частям. И опять же про оценку эффективности. Если мы толком не знаем, как мерить эффективность процесса управления изменениями, значит, мы и при его проектировании ничего не мерили, методики то нет, значит, не знали, снизят ли принимаемые меры негативное влияние или нет?
        В целом же, не смотря на отдельные вопросы, я с Вашими мыслями, Евгений, согласен. В отдельных случаях, когда акцент изначально на конфиге (а так далеко не всегда), можно поначалу использовать упрощенный процесс управление изменениями. Более того, нечто подобное мы с коллегами сейчас продумываем для нашего хромого процесса управления изменениями.

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

          “мне вот всегда попадалась более-менее упорядоченная деятельность по реализации изменений при гораздо худшей деятельности по управлению конфигурации”

          Я согласен с такой оценкой.

          • Евгений Шилов

            Если вы имеете ввиду тот факт, что изменения как-то реализовывались, а информация об инфраструктуре собиралась разрозненно и от случая к случаю, то конечно вы правы.

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

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

              “которая может быть направлена на достижение определенных целей, например таких как, обновление CDMB”

              Очень спорная цель. Если есть кипучая энергия, её лучше направлять в мирное русло, чем на обновление CMDB 🙂

              • Евгений Шилов

                Почему спорная? Если есть задача обновления CMDB, есть деятельность, которую можно скорректировать, для того чтобы решалась в том числе и такая задача.
                В чем спорность? В теории не так написано?

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

                  Это спорная цель для управления изменениями. И в теории, а на практике.

                  • Евгений Шилов

                    Как отправная точка почему нет? Еще раз, повторю вопрос: “в чем спорность?”.

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

                      Потому что процесс начинает строиться совсем не для того, для чего он предназначен. Если chg не нужен, зачем его внедрять для обновления CMDB – не понимаю. Лучше его не внедрять. С таким же успехом можно установить цель обновления CMDB для управления проблемами или внедрить для этого “на будущее, чтоб пока привыкали” управление непрерывностью ИТ-услуг 🙂

                  • Евгений Шилов

                    Дим, к твоему последнему комментарию, т.к. дальше дерево комментов уже не строится 🙂

                    Ты слишком категоричен в выводах. Не могу с тобой согласиться. Отмечу лишь, что не предлагаю делать целью всего процесса управления изменениями “обновление CMDB” раз и навсегда. А как отправная точка – это жизнеспособный вариант, подтвержденный практикой. Т.к. свалить на людей абсолютно новую культуру ведения изменений с согласованиями, приоритетами т.д. сложнее, чем научить их сначала все изменения проводить через процесс, а затем нарастить в нем мяса.

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

                      “Ты слишком категоричен в выводах”

                      Простите. Я больше не буду.

                      “как отправная точка — это жизнеспособный вариант, подтвержденный практикой”

                      А если на практике внедрить для обновления cmdb управление непрерывностью ИТ-услуг (чтобы пока привыкали), то практика покажет, что и это жизнеспособный вариант 🙂

  • Михаил Тобурдановский

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

    • Евгений Шилов

      Если процесс изначально задумывался не только ради регистрации, то сдается мне, что это риск.

  • Leonid

    «Мыслей по этому поводу конечно же еще вагон»
    А давайте и я из своего вагона выгружу мыслишку на заданную тему.;)

    А зачем вообще нужен самостоятельный процесс управления конфигурации?

    Например, в нашем текущем проекте конфиг реализован как самостоятельный процесс, состоящий укрупнено из 5 практически автономных видов деятельности:
    1) Первичное наполнение CMDB – выполняется при создании или при глобальной перестройке CMDB, фактически разовая деятельность.
    2) Обновление данных CMDB – в основном внесение изменений в CMDB по результатам реализации изменений.
    3) Устранение расхождений в CMDB – корректировка информации о CI по результатам периодических аудитов CMDB.
    4) Предоставление информации – выдача информации из CMDB по запросу, когда автор запроса не имеет доступа к CMDB.
    5) Формирование и предоставление отчетности – отчетность по процессу.

    Все вроде бы красиво и по ITIL, но на практике вышло следующее:

    Деятельность «1» не процесс, а скорее проект, по крайней мере, на практике реализуется именно как проект, и включение такой деятельности в постоянно действующий процесс кажется излишним.
    Деятельность «2» является самой содержательной частью процесса. Изначально предполагалось, что ограничение числа специально подготовленных специалистов (учетчиков), вносящих информацию в CMDB, позволит обеспечить надлежащую корректность информации в CMDB. Однако на практике права учетчиков быстренько раздали всем, и разделение на исполнителя изменения и учетчика стало чисто формальным. Таким образом, данная деятельность растворилась в управлении изменениями.
    Деятельность «3» конечно нужна, но ее существование в отдельном процессе вызывает сомнение т .к. у нас уже есть процесс «Контроля и оценки», в рамках которого осуществляется контроль над всеми процессами. Логичным кажется осуществление и этой деятельности в рамках процесса «Контроля и оценки».
    Деятельность «4» вообще ни разу не выполнялась, так как доступ к CMDB имеют все сотрудники, имеющие хоть какое-то отношение к ИТ-инфраструктуре.
    Деятельность «5» свелась к отчетам по % заполнения CMDB, а так как это разовая деятельность, то и такая отчетность к процессу фактически не относиться.

    Вот и получается, что тяжеловесный конфиг, пожирающий массу ресурсов, мог быть реализован в виде пары процедур в процессе управления изменениями и в процессе «Контроля и оценки», плюс разовый проект по созданию CMDB. А вы как думаете?;)

    • Евгений Шилов

      1. “Первичное наполнение CMDB – выполняется при создании или при глобальной перестройке CMDB, фактически разовая деятельность.”

      Наполнение CMDB или “инициализация” должна выполняться каждый раз, когда меняются правила учета. И это не обязательно “глобальная перестройка”. Фактически это деятельность завязанная на цикл пересмотра плана управления конфигурациями. Если в плане меняется что-то , требующее сбора дополнительной информации, то выполнять эту процедуру придется.
      Такая работа действительно может выполняться в виде проекта, но по правилам предусмотренным в рамках процесса.

      2. Раздача “прав учетчиков” – это воля менеджера процесса. Если он готов обеспечивать целостность CMDB и соблюдение правил учета, когда каждый первый – “учетчик”, то почему бы и нет. Вопрос только в том, как он это собирается делать?

      3. Насколько я понимаю, контроль и оценка – периодическая деятельность, направленная на оценку работы процессов и подготовку мероприятий по совершенствованию. А устранение расхождений в имеет два входа: аудиты CMDB, которые действительно можно привязать к аудитам процессов, но аудиты CMDB могут быть не только периодическими, но и привязанными к значимым событиям, например, нашли большое количество расхождений.

      4. Бывает 🙂

      5. А это уже вопрос к тому как строится контроль работы процесса, % заполнения CMDB не единственный важный показатель. С учетом п.2. мне бы например была интересна актуальность данных, соблюдения правил учета.

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

    • Евгений Шилов

      Леонид, тема интересная, поэтому вынес в отдельный пост (http://www.realitsm.ru/2011/10/upravlenie-konfiguraciyami-process-ili-procedura)

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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
Авторы и редакторы портала — консультанты и тренеры компании Cleverics.
Использование материалов данного сайта допускается исключительно с разрешения правообладателя.
Использование данного сайта означает согласие с обязательством соблюдать нашу Политику конфиденциальности и Согласие на обработку персональных данных.