Опубликован: 12.11.2012 | Доступ: свободный | Студентов: 1817 / 306 | Длительность: 18:27:00
Лекция 8:

Домен "Приобретение и внедрение": процессы, отвечающие за поставку ИТ-ресурсов, управление и реализацию изменений

< Лекция 7 || Лекция 8: 123 || Лекция 9 >

8.2. AI 6. Управление внесением изменений

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

  • оптимизация рисков;
  • минимизация негативного влияния на бизнес со стороны ошибок и сбоев;
  • успешная реализация изменений с первой попытки.

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

Стандартные действия при реализации отдельных изменений:

  • создание Запроса на изменение (RFC);
  • пересмотр и проверка RFC, фильтрация изменений;
  • оценка и определение изменения:
  • установить уровень управления изменением;
  • определить участников процесса;
  • оценить мотивацию бизнеса, издержки, риски и выгоды, связанные с изменением;
  • запросить независимую оценку изменения.
  • утверждение изменения (в том числе определение механизмов авторизации к нему);
  • формирование планов обновлений;
  • координация реализации изменения.
  • обзор и завершение изменения[5].
Процесс "Управление внесением изменений"

Рис. 8.2. Процесс "Управление внесением изменений"

Управление внесением изменений.

удовлетворяет следующим бизнес требованиям к ИТ

соответствие бизнес требованиям в русле корпоративной стратегии, при сокращении дефектов и переделок в решениях и услугах.

сосредоточено на

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

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

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

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

В таблице 8.5 представлена информация, необходимая для процесса и ее источники.

Таблица 8.5.
Источник Входящая информация
PO 1 Портфель ИТ-проектов
PO 8 Действия по повышению уровня качества
PO 9 Планы действий по минимизации ИТ-рисков
PO 10 Рекомендации по управлению проектами и детальные планы проектов
DS 3 Требуемые изменения
DS 5 Требуемые изменения в области безопасности
DS 8 Запросы на обслуживание/изменения
DS 9-10 Запросы на изменения
DS 10 Журнал проблем

В таблице 8.6 приведены результаты процесса и то, куда они должны поступить.

Таблица 8.6.
Результаты В процессы
Описание процесса изменений AI 1..AI 3
Отчеты о статусе изменений ME 1
Авторизация изменений AI 7 DS 8 DS 10

Таблица 8.7 содержит таблицу ОУКИ для процесса, а таблица 8.8 – цели и показатели.

Таблица 8.7.
Действия\Функции Президент Финансовый директор Высшее руководство Директор по ИТ Владелец бизнес-процесса Руководитель эксплуатации системы Главный архитектор ИТ-системы Руководитель разработок Руководитель администрации ИТ Руководитель проектного офиса Аудит, риски, безопасность
Разрабатывать и реализовывать процесс постоянного учета, оценки и расстановки приоритетов в запросах на изменения У И О К О К К К
Оценивать последствия и расставлять приоритеты в изменениях на основе требований бизнеса И О У/О К О К О К
Обеспечивать соответствие аварийных и критических изменений утвержденному процессу И И У/О И О К
Утверждать изменения И К У/О О
Управлять значимой информацией об изменениях и распространять ее У И О К О И О К
Таблица 8.8.
Цели Показатели
ИТ:
  • обеспечить соответствие требованиям бизнеса в рамках корпоративной стратегии
  • минимизировать дефекты и переделки в решениях и оказании услуг
  • минимизировать последствия сбоя или изменений в услугах ИТ для организации
  • число сбоев и ошибок в данных, вызванных неточными спецификациями или неполной оценкой последствий
Процесса:
  • внести авторизованные изменения в ИТ-инфраструктуру и приложения
  • оценить последствия изменений для ИТ-инфраструктуры, приложений и технических решений
  • отслеживать и отчитываться о статусе изменений перед основными заинтересованными сторонами
  • минимизировать ошибки, вызванные неполными спецификациями при запросах на изменения
  • количество переделок в приложениях или инфраструктуре, вызванных неверными спецификациями изменений
  • сокращение времени и усилий, необходимых для внесения изменений
  • доля аварийных изменений от общего числа вносимых изменений
  • доля неудачных изменений в инфраструктуре из-за неадекватных спецификаций на изменения
  • число формально не отслеживаемых, неавторизованных и не вошедших в отчетность изменений
  • число невыполненных запросов на изменения, то есть очередь запросов
Действия:
  • определение и информирование о процедурах внесения изменений, в том числе аварийных
  • оценка, выстраивание приоритетов и авторизация изменений
  • планирование расписания внесения изменений
  • мониторинг статуса и отчетность об изменениях
  • доля изменений, учтенных автоматизированными системами
  • доля изменений, которые производятся в соответствии с формализованным процессом контроля
  • соотношение принятых и отклоненных запросов на изменения
  • количество различных версий каждого из поддерживаемых корпоративных приложений
  • количество и характер аварийных изменений в компонентах инфраструктуры
  • количество и тип обновлений/исправлений, внесенных в компоненты инфраструктуры

Цели контроля

  • AI 6.1. Стандарты и процедуры изменений

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

  • AI 6.2. Оценка последствий, расстановка приоритетов и авторизация

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

  • AI 6.3. Аварийные изменения

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

  • AI 6.4. Мониторинг и отчетность по статусу изменений

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

  • AI 6.5. Завершение изменений и документирование

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

Управление изменениями представляет ценность для бизнеса тем, что:

  1. категорирует цели изменений бизнеса и заказчиков и помогает их осуществить;
  2. реализует изменения, которые соответствуют потребностям заказчиков, одновременно с оптимизацией затрат;
  3. старается выполнять требования закона, контрактов, руководства и регуляторов;
  4. уменьшает количество неудавшихся изменений и, соответственно, количество сбоев, остановок и простоев услуг;
  5. осуществляет изменения в установленном бизнесом временном интервале;
  6. следит за изменениями на всем жизненном цикле услуг;
  7. старается обеспечить лучшие показатели в аспектах качества, времени и затрат;
  8. оценивает риски, сопутствующие внедрению;
  9. помогает увеличить продуктивность работы персонала тем, что минимизирует нарушения и сбои, а, следовательно, улучшает доступность услуг.

Рассмотрим пример. Однажды внедренная ИТ-услуга (платформа для публикации произведений) требует изменений – необходимых, желаемых, нежелательных и т.п. Например:

  • для приложений это могут быть баги и улучшения. Некоторые баги могут быть критичными (например, исправление уязвимости, которая позволяет злоумышленникам получать доступ к учетным записям пользователей), некоторые – незначительными.
  • для операционных систем могут быть обновления, патчи и новые версии;
  • для аппаратного обеспечения может потребоваться дополнительная RAM или увеличение количества жестких дисков;
  • организация может изменить политику информационной безопасности. Например, ужесточить требования к сложности паролей.
  • могут измениться параметры таймаута сессии – с 30 минут на 10 минут и т.п.

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

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

Важным аспектом процесса является необходимость документирования всех изменений. Представим ситуацию, когда над созданием системы в организации работает около 100 человек из различных отделов. Допустим, один из программистов нашел ошибку и , будучи уверенным в своей правоте, исправил ее. Приложение стало давать сбои. Если процесса контроля над изменениями нет, то найти причину отказа будет крайне сложно, так как ежедневно большая часть команды вносит в него изменения. Хорошо структурированные и запланированные изменения помогают бизнесу сократить издержки и повысить эффективность.

< Лекция 7 || Лекция 8: 123 || Лекция 9 >
Максим Цапко
Максим Цапко

Я наконец закончил курс "Управление ИТ-проектами". Как получить документ об окончании курса.

Дмитрий Лобанов
Дмитрий Лобанов

Управление ИТ на основе COBIT 4.1

: в перечне литературы, п.15 - отсутствует документ по ссылке https://www.rusonyx.ru/support/agreements/

Алексей Янов
Алексей Янов
Россия, Москва, МГТУ им Н.Э.Баумана, 2002
Сергей Уткин
Сергей Уткин
Россия