Бурный рост рынка услуг вызывает необходимость в эффективных бизнес-процессах. Постоянное изменение требований и стандартов требует высокоразвитой ИТ-инфраструктуры. А кроме того, влечет за собой огромное количество изменений инфраструктуры. В условиях мировых экономических кризисов повышение эффективности становится еще более актуальной проблемой. И здесь всплывает острая необходимость управлять изменениями в ИТ.
На мой взгляд, основные проблемы в управлении происходят из следующих причин.
- Изменения не согласовываются и не доносятся до заинтересованных лиц. Например, вносятся изменения в сервер. Те сотрудники, которые не были уведомлены об этом ожидают, что новый релиз выйдет и нормально запустится на старых компонентах. В итоге же сервер, неожиданно, не запускается совсем.
- Независимость изменений, вносимых разными людьми. Например, два человека или две удаленные команды меняют независимо друг от друга что-то на продакшн-сервере. Их действия, вполне вероятно, могут привести к конфликтам или неожиданным результатам.
- Отсутствие документирования изменений. Например, внесли небольшие изменения и не задокументировали. Это не так критично, как в предыдущих примерах, но изменения накапливаются и, в конце концов, приходится полностью переписывать документацию. А если на предприятии меняется ответственный персонал, то проблема становится очень критичной.
Понятно, что в сегодняшних реалиях процесс управления изменениями не выглядит простым.
В мировой практике используют различные методологии и стандарты для решения этих задач. Но, в общем и целом, управление изменениями представляется как циклический комплекс мер. На рисунке 1 представлены основные этапы этого цикла.
Рисунок 1-Процесс управления изменениями
Для организации этого процесса сначала надо разобраться с существующей ИТ-инфраструктурой: сервера, сервисы и т.д. Необходимо знать уровни предоставления сервисов и базовые конфигурации. Это может понадобиться в случае неудачного изменения (для восстановления системы в прежнее состояние), а также, для обеспечения одинакового уровня доступности услуг с точки зрения заказчиков.
Следующим этапом должно быть внедрение методологии для управления изменениями. В мировой практике уже используются разработанные методологии (ITIL, ASAP), однако каждое предприятие может использовать свои уникальные наработки, опираясь на свой управленческий опыт.
Далее необходимо выбрать инструмент, с помощью которого будет удобно построить необходимые процессы на предприятии. Далее по тексту я буду упоминать продукт Atlassian Jira, так как это, по моему мнению, очень удобный инструмент для планирования, обработки и отслеживания запросов на изменения, а также регистрации событий, приводящих к изменениям или последующих за изменениями.
Рисунок 2-Atlassian Jira — инструмент для управления изменениями
Имея подробные исходные данные можно переходить к следующему этапу управления – планированию. Для того, чтобы запланировать изменения давайте разберемся, какими они могут быть.
Типы изменений
Основные типы изменений для основного количества компаний можно перечислить исходя из схемы на рисунке 1. Это:
- Изменение или добавление конфигураций
- Управление релизами и развертыванием
- Управление инцидентами
- Разрешение проблем
- Инновационные изменения
Каждый тип изменений имеет свою сложность, важность и срочность. Поэтому, имеет смысл присваивать разные приоритеты задачам на внесение изменений.
В зависимости от специфики деятельности предприятия типы изменений необходимо стандартизовать.
Чаще всего изменения можно разделить на три типа:
Стандартное изменение – это изменение, которое можно назвать рутинным. Имеет стандартный и четкий набор операций. Не влечет за собой рисков, не требует больших ресурсов. Примером такого изменения может быть добавление или удаление пользователя из системы, установка нового персонального оборудования (ПК, мобильные устройства, принтеры и т.п.).
Экстренное или корректирующее изменение – это изменение, призванное восстановить системы после сбоя или предотвратить сбой или критическое состояние оборудования или систем.
Нормальное изменение – изменение, внедряемое в рамках проекта и являющееся его этапом. Например, Управление релизами.
Оценка ресурсов и связанные процессы
Чтобы была возможность контролировать все изменения, они должны быть соответствующим образом зарегистрированы. Целесообразно начинать процесс регистрации изменения с создания соответствующего запроса. Продукт Jira Service Desk имеет внушительный набор стандартных запросов, покрывающих потребности любой ИТ-службы.
Рисунок 3-Типы запросов Jira для стандартных изменений
Рисунок 4-Типы запросов Jira для экстренных или нормальных изменений.
После регистрации запроса в системе запускается стандартизированная процедура обработки запроса. В общем виде она должна в себя включать подтверждение или согласование, реализацию, проверку и документирование.
Этап подтверждения или согласования нужен для оценки целесообразности и эффективности предложенного изменения. Здесь нужно внимательно подойти к оценке ресурсов и влияний изменения. Команда, или назначенный комитет должен оценить:
- Функциональные требования к проекту
- Перечень лиц или отделов, которых касается изменение
- Критерии оценки успешности изменений
- Временные и денежные рамки
- Перечень лиц или отделов, ответственный за внедрение изменения.
На основании перечисленных выше оценок и тестирования требований принимается решение об изменении.
Степени воздействия изменений
Тщательная оценка должна выявить степени воздействия изменений на связанные системы и бизнес-процессы. В зависимости от степени воздействия может быть разработана таблица приоритетов изменений. Строго говоря, это ранжирование обязательно для компании любого размера и профиля, так как облегчает и стимулирует правильную обработку запросов на изменение ИТ-отделами. Приоритет так же зависит от типа изменения.
Мне кажется эффективным подход, который предполагает назначение ролей специалистам. В зависимости от своей роли специалист может инициировать и согласовывать только изменения определенного приоритета.
Например, типы инициаторов могут быть такими: инициаторы проекта, инициаторы конфигурационных изменений, инициаторы корректирующих изменений. В зависимости от степени воздействия разные люди входят и в комитет по согласованию.
Реализация изменения
Внедрение изменения представляется самым важным и сложным этапом. Но, с организационной точки зрения, — это самый простой этап. Особенно, если последовательно были проведены предварительные этапы: планирование, классификация и оценка. В таком случае, должны быть уже определены все цели, критерии и ответственные лица. Работа происходит в соответствии с существующими workflow. Инструменты наподобие Jira позволяют полностью контролировать этот процесс.
Отчеты и документирование
После реализации изменения надо провести анализ, позволяющий ответить на вопросы:
- Была ли решена задача, которую ставили при планировании изменения?
- Изменился ли перечень предоставляемых ИТ-услуг?
- Оправдались ли ожидания заказчиков изменения?
- Не нарушена ли работа связанных систем и сервисов?
Все это удобнее всего анализировать, имея систему разработанных отчетов.
После этого можно приступать к одному из самых важных этапов – документированию изменений. Здесь надо учесть следующие моменты:
- Все заинтересованные лица должны быть уведомлены о внедрении изменений.
- Все операции сделанные в процессе внедрения изменения должны были быть задокументированы.
- Должна быть сформирована база знаний, где регистрируются возникающие в процессе изменения проблемы и пути их решения.
- Должны быть написаны обновленные рекомендации по эксплуатации.
Итоги
Для решения всех, перечисленных в начале статьи проблем кажется очевидным решение проводить все изменения в соответствии с разработанной процедурой. Однако, есть риск усложнить процесс внесения типовых (с точки зрения реализации) или стандартных задач. Поэтому, имеет смысл выделять такие задачи в отдельную группу и проводить их по специальному упрощенному сценарию. Здесь можно «сэкономить» на согласовании и, возможно, документировании.
Рисунок 5-Пример workflow в Jira для нормального изменения
Рисунок 6-Пример workflow в Jira для экстренного изменения
Основной целью процесса управления должна быть относительная независимость от конкретных ИТ-специалистов. То есть новый человек должен разобраться в состоянии ИТ-инфраструктуры за минимальное время, с минимальным привлечением ресурсов и при непрерывности ИТ-услуг.
Однако, такая цель может показаться слишком размытой. Поэтому в каждом конкретном случае нужно разрабатывать набор критериев, по которым определяется эффективность управления изменениями, их польза и непрерывность работы ИТ-инфраструктуры.
Например, список критериев может быть таким:
- Уменьшение времени вынужденного простоя из-за экстренных или незапланированных изменений в системах.
- Повышение эффективности персонала в связи с внедрением новых решений в ИТ-инфраструктуре.
- Повышение отказоустойчивости систем.
- Снижение времени восстановления систем после сбоев.
- Оптимизация инфраструктуры
Сложности в процессе управления изменениями.
При внедрении управления изменениями необходимо учитывать следующие возможные сложности:
- Персонал может не соблюдать правила ведения учета изменений, мотивируя это нехваткой времени на собственно оказание ИТ-услуг
- Необходимость обосновывать «бизнесу» затраты на процесс управления изменениями
- Перегруженность процесса сбором лишней информации и составлением избыточного количества отчетов
- Недостаточное разъяснение персоналу сути процесса и методологии
Все эти сложности могут возникать периодически по мере роста предприятия, поэтому необходимо своевременно пересматривать методики управления изменениями ИТ-инфраструктуры для поиска наиболее эффективных решений.
Добрый день, Виктор!
Подскажите пож-ста, по Вашему мнению, к примеру, запрос на создание нового отчета в ИС или запрос на модификацию отчета нужно классифицировать как запрос на изменение?
Спасибо!