апрель    2024

Пн	Вт	Ср	Чт	Пт	Сб	Вс
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30

показать все 

22.04.2024

Сообщество цифровых управленцев «я-ИТ-ы» проводит ЗАКРЫТУЮ встречу в рамках выставки «Связь-2024»!

Читать далее 

18.04.2024

Ассоциация разработчиков «Отечественный софт» отметила 15-летие

Читать далее 

17.04.2024

РДТЕХ представил Технологическую карту российского ПО 2023

Читать далее 

16.04.2024

RAMAX Group получила партнерский статус уровня Gold по продукту Tarantool

Читать далее 

показать все 

18.04.2024

5 способов повысить безопасность электронной подписи

Читать далее 

18.04.2024

Как искусственный интеллект изменит экономику

Читать далее 

18.04.2024

Неочевидный САПР: выход ПО за рамки конструкторской деятельности

Читать далее 

18.04.2024

Скоро некому будет делать сайты и заниматься версткой

Читать далее 

18.04.2024

Цифровая трансформация в энергетике: как запустить проект с максимальным финансовым эффектом?

Читать далее 

05.04.2024

Мотивируй, не то проиграешь!

Читать далее 

22.03.2024

В 2024 году в России и мире вырастут объемы применения AR/VR 

Читать далее 

25.02.2024

Цифровые технологии: надежды и риски

Читать далее 

05.02.2024

Будут ли востребованы услуги технической поддержки софта Oracle в России в ближайшие годы?  

Читать далее 

31.01.2024

Здания с признаками интеллекта. Как Сергей Провалихин автоматизирует дома и производства

Читать далее 

показать все 

Главная / Архив номеров / 2017 / Выпуск №06 (69) / Изменение ИТ-процессов: да здравствует разумная гибкость!

Рубрика: ИТ-процессы

Марина Аншина, президент Фонда ФОСТАС, председатель Комитета по стандартам Российского Союза ИТ-директоров

Изменение ИТ-процессов:
да здравствует разумная гибкость!

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

Вот это определение «изменение – понятие, входящее в состав совокупности понятий, характеризующих движение и развитие. Изменение понимается как возникновение или уничтожение свойств объекта, увеличение или уменьшение егопараметров, его перемещение или преобразование, переход в иную форму».

Если в первой части определения явственно проглядывает его позитивный смысл, то вторая неявно показывает, что есть и негативная сторона. Ведь свойства можно потерять и полезные, да и изменение параметров объекта может значить все что угодно. Однако многие из нас изменения скорее не любят, а некоторые прикладывают массу усилий, чтобы не допустить их ни в свою жизнь, ни в профессиональную деятельность. Согласитесь, что вести себя подобным образом стем, что «характеризует движение и развитие», по меньшей мере неразумно.

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

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

Рисунок 1. Классификация организаций по Минцбергу

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

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

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

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

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

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

Если сами бизнес-процессы нестабильны, если при этом они все активнее втягивают в себя современные ИТ, то насколько стабильны могут быть поддерживающие их ИТ-процессы? Философский вопрос «ИТ – это тормоз или двигатель дляразвития компании?» становится чуть ли не более популярным, чем «Быть или не быть?». Во многих компаниях можно наблюдать, как ИТ не только не способствуют, но препятствуют развитию. О какой уж тут цифровой трансформации может идти речь! Таким образом, качество управления изменениями процессов ИТ является уже не только одной из важнейших задач подразделения ИТ, но выходит на уровень важнейших приоритетов всей компании.

Осознав значительную роль управления изменениями, надо взглянуть, что нам может помочь этот процесс усовершенствовать. Ведь глупо изобретать велосипед, если на нем уже давно ездят. Начнем с библиотеки лучших практик ITIL. Азаодно вспомним и о ITSM. В первой версии ITSM процесс управления изменениями наряду с процессом управления конфигурациями представлял собой тот стержень, на который нанизывались другие процессы.

Рисунок 2. ITSM образца начала века

В последних версиях ITSM, как видно из рис. 3, управлению изменениями пришлось потесниться, и его центральная роль в управлении процессами ИТ оказалась занята такими процессами, как непрерывное улучшение сервиса, отчетность и стратегическое управление. Воистину «лучшее – враг хорошего». Никоим образом не хочу спорить с разработчиками ITSM и ITIL о важности того или иного процесса. В конце концов они все важны, прямо как в детском стишке, где, правда, речь идет о мамах: «Процессы разные нужны, процессы всякие важны….» Но попытка «впрячь в одну телегу коня и трепетную лань», т.е. процессы стратегического и оперативного управления, по-моему, оказалась разрушительной для технологии.

Рисунок 3. ITSM сейчас

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

1. Формировать заявки на изменения, включая изменения самих процессов (Request for Change или RFC).
2. Анализировать их, определяя затраты на их реализацию, выгоды и риски, которые они могут принести компании.
3. Согласовывать их на основе результатов анализа на Комитете по изменениям (Change Advisory Board – CAB) и вносить соответствующие изменения в план реализации изменений.
4. Выполнять изменения в соответствии с планом.
5. Проверять и внедрять их в деятельность компании.
6. Описывать изменения и вносить соответствующие поправки в связанную с изменениями документацию.
7. Анализировать результаты и постоянно улучшать процесс управления изменениями.

Конечно, есть и лазейка – так называемые срочные изменения. То есть если очень надо что-то быстро поме-нять, то необходимо только определить, кто возьмет ответственность на себя, и, конечно, сделать то, что нужно. А уж потом, как рекомендует ITIL, пройти всю вышеприведенную цепочку действий.

Проблем тут много. Основная состоит в том, что срочных изменений становится все больше и, как вы прекрасно понимаете, когда они уже сделаны, мало кто бывает озабочен тем, чтобы «задним числом» их проанализировать, согласовать и описать. То есть при увеличении количества срочных изменений вся с трудом налаженная система Change Management начинает рушиться.

К счастью, мы с вами занимаемся только одним типом изменений – изменениями процессов ИТ, среди которых срочные попадаются очень редко. Поэтому нам никто не мешает взять за основу процесс, описанный в ITIL.

Как и для каждого процесса, в чем я, несомненно, соглашусь с ITIL, он предлагает начать с определения целей.

Цели процесса управления изменениями могут быть, например, следующими:

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

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

Далее, руководствуясь ITIL, надо понять, каким образом информация о необходимости изменений будет поступать в наш процесс, т.е. определить входы. ITIL рекомендует три типа входов:

• Уже упоминавшиеся выше RFC – запросы на изменения.
• База конфигурационных единиц CMDB – в нашем случае это база процессов (не только ИТ).
• План выполнения изменений (FSC) – Forward schedule of change.

Если у вас налажен процесс управления изменениями, то изменения процессов ИТ будут одним из типов таких изменений. В этом случае у вас скорее всего внедрен Service Desk, который предусматривает разные каналы поступления заявок на изменения: через ПК или мобильное устройство, заполнив специальную форму через браузер, по телефону, по электронной почте, через СМС и т.д. Кроме этого, для изменений ИТ надо предусмотреть вход из других процессов, например процесса управления активами и процесса управления инцидентами.

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

1. Проанализировать заявку на предмет ее адекватности, выполнимости, соответствия потребностям компании, т.е. пропустить ее через тот фильтр, который вы считаете разумным.
2. Обработать прошедшие фильтр заявки, чтобы определить ориентировочные сроки и необходимые ресурсы, их выгоду и затраты на их реализацию.
3. На основе этого анализа регулярно (обычно раз в неделю) собирающийся Комитет по изменениям (САВ) утверждает новые изменения и корректирует оперативный план выполнения изменений.
4. На основании плана изменения выполняются в тесном взаимодействии с процессом управления релизом.
5. Весь процесс сопровождается разработкой и/или обновлением документации.
6. После закрытия изменения обновляется база знаний, проводится анализ и при необходимости принимаются меры, например, по улучшению процесса управления изменениями.

Наибольшие вопросы у меня вызывает САВ, поскольку всем известно, насколько трудно втянуть топ-менеджмент в управление ИТ. Поэтому в реальности вместо САВ обычно предусматривают заочные согласования или другие усеченные варианты.

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

Люди обычно делятся на две категории: те, кто живет по принципу «Лучше жалеть о том, что сделано, чем о том, что не сделано», и те, кто рассуждает прямо противоположно. Лично я стараюсь в последнее время следовать первой сентенции. А вы?

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

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

Важны параметры изменения:

• Инициатор изменения.
• Цель изменения.
• Область изменения.
• Влияние изменения на другие процессы и проекты.
• Риски и возможности, связанные с реализацией изменения.
• Риски, связанные с нереализацией изменения.
• Срок, к которому изменение должно быть реализовано (строгий или ориентировочный).
• Ресурсы, необходимые для выполнения изменения (риски, бюджет, оборудование, ПО).
• Согласующие лица – об этом мы еще поговорим.
• Статус изменения: например, открыто, проанализировано, согласовано, отклонено, запланировано, выполняется, выполнено, заморожено, закрыто.

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

1. Не приведет ли изменение к неблагоприятным для компании результатам с учетом всей архитектуры компании, а не только этого процесса.
2. Превышают ли выгоды от изменения затраты на него (т.е. эффективно ли оно).

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

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

• Возможностями и рисками.
• Выгодами и затратами.
• Удовлетворенностью пользователей и потребностями заказчиков.

В случае управления изменениями процессов ИТ можно предусмотреть согласующие лица, такие как:

• Владелец1 изменяемого процесса.
• Владельцы связанных процессов.
• Архитектор бизнеса, архитектор ИТ.
• Бизнес-аналитик.
• Руководители ИТ и ключевые сотрудники служб, выполняющих ИТ-процессы.
• Ответственный за информационную безопасность.
• Ответственный за качество информации.

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

• По причине инициации.
• По степени важности для компании.
• По уровню риска.
• По уровню затрат.

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

ITIL рекомендует следующие параметры процесса управления изменениями:

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

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

В качестве областей изменения процесса управления изменениями я бы предложила следующие:

• Гибкость – соответствие гибкости процессов потребностям бизнеса (требованиям заказчиков).
• Клиенты – удовлетворенность пользователей обслуживанием, в частности качеством внедрения изменений.
• Эффективность – соотношение выгод и затрат, в частности сколько стоят изменения и какую ценность они имеют для бизнеса.
• Взаимодействие – насколько удовлетворены выполнением изменений процессов сотрудники, которые эти процессы выполняют и обслуживают.

И упаси вас от лобового контроля процесса по нескольким несвязанным параметрам. И тем более от привязывания к ним системы мотивации.

Несколько слов о документации и моделировании. Это больное место большинства ИТ-процессов. Зачастую появляются модели, которые уже давно не соответствуют образцу. Если вы начали заниматься моделированием, все равно каким способом: хоть текстовым описанием, хоть BPMN, не забудьте предусмотреть процедуру обновления моделей при изменении процессов. Потому что лучше вовсе не иметь никакой модели, чем иметь несвежую. Так ведь и«отравиться» можно.

И еще немного про внедрение изменений процессов ИТ. Необходимо предусмотреть оповещение всех, на кого изменение может повлиять, с объяснением того, зачем это делается.

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

А вооруженные знанием, как организовать процесс управления изменениями процессов ИТ, не будем бояться делать их лучше на радость нашим пользователям и заказчикам. Долой нездоровый консерватизм и да здравствует разумная гибкость!

1 Надеюсь, что у вас есть владельцы хотя бы основных процессов ИТ, т.е. те, кто отвечает как за их выполнение, так и за усовершенствование, и имеет все необходимые полномочия и права для выполнения своих обязанностей.

В начало⇑

Комментарии отсутствуют

Комментарии могут отставлять только зарегистрированные пользователи