на главную поиск по сайту карта сайта
+7 (495) 646-0612info@informicus.ru

Оформить заказ

Оказываем полный спектр услуг в сфере информационных технологий. Разработка, внедрение и сопровождение программного обеспечения. Анализ, оценка эффективности и консультирование в сфере использования информационных систем. А также собственные программные решения для оптимизации вашего бизнеса.
Разработка программ, разработка ПО на заказ, торговые роботы    
ГЛАВНАЯ О КОМПАНИИ РЕШЕНИЯ УСЛУГИ СТАТЬИ

СТАТЬИ

СТАТЬИ

К оглавлению.

Управление изменениями

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

Схема процесса управления изменениями

Общая схема проведения изменений начинается с регистрации запроса на изменения — Request for Change (RFC) . Ему присваивается идентификационный номер, и в дальнейшем осуществляется классификация запроса, то есть фактически определяется сценарий, по которому данный запрос будет обрабатываться. Многие компании считают необходимым следовать одному сценарию процесса для всех изменений.

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

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

Приоритеты изменений могут быть следующими:

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

Число и описание приоритетов в каждой компании могут быть различными, но на выбор приоритета всегда должны влиять категории изменений с точки зрения их масштабности, например:

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

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

  • Финансовое одобрение: анализ затрат/выгод бюджета.
  • Техническое одобрение: оценка необходимости, возможности проведения изменения и степени его воздействия.
  • Бизнес-одобрение: одобрение пользователями требуемой функциональности приложения и степени воздействия изменения.

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

Для обеспечения вышеуказанных условий создается группа согласования и подтверждения изменений (Change Advisory Board ), которая является неотъемлемой частью всего процесса и включает в себя представителей различных подразделений с обязательным участием руководства финансовых подразделений и руководства компании (за которым остается право окончательного решения).

В небольших компаниях достаточно одной такой группы, в более крупных возможно существование нескольких групп, что позволяет рассмотреть запросы и планы изменений представителями разных служб, что впоследствии снижает вероятности рисков неудачных или невостребованных изменений. Кроме того, группы обеспечивают взаимодействие между IT и бизнес подразделениями для определения их согласованной точки зрения на изменение. Для выполнения этих задач в группы следует включать людей, знакомых с бизнес-процессами предприятия и его информационными системами. После утверждения запроса на изменение или графика будущих изменений (FSC — Forward Schedule of Change ) — документа, описывающего порядок изменений и задействованные ресурсы, на специально формируемом совещании проектные группы могут начинать внедрять утвержденные изменения в деятельность компании.

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

При этом основными задачами владельца процесса управления изменениями являются:

  • руководство процессом;
  • фильтрация и классификация запросов на изменения;
  • принятие решений для небольших запросов на изменения;
  • взаимодействие с заказчиком изменений;
  • планирование изменений;
  • координация изменений;
  • анализ успешности изменений.

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

На основе данных моделей очень просто получить регламент процесса и ролевые инструкции его участников.

Анализ эффективности изменений

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

Для обеспечения контроля за эффективностью управления изменениями необходимо анализировать следующие ключевые показатели результативности:

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

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

  • Привело ли изменение к достижению намеченной цели?
  • Удовлетворены ли пользователи результатом?
  • Возникали ли какие-либо побочные эффекты?
  • Были ли превышены расчеты по затратам и ресурсам?

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

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

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

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

««НазадДалее»»

90
Проектное управление
Проектное управление
Подробнее
89
Аспекты проектного управления
Аспекты проектного управления
Подробнее
82
Что такое Rational Unified Process (RUP)
Что такое Rational Unified Process (RUP)
Подробнее
73
Цикл статей по моделированию программных систем
Цикл статей по моделированию программных систем
Подробнее
1234

телефон/факс: +7 (495) 646-0612/687-9964

105120, г. Москва, ул. Нижняя Сыромятническая,д. 5/7

info@informicus.ru

COPYRIGHT INFORMICUS, 2006 - 2020

Главная | О компании | Решения |
Услуги | Статьи | Карта сайта