В системах управления качеством (QMS) и системах информационных технологий (IT) контроль изменений — это процесс, формальный или неформальный [1] , используемый для обеспечения того, чтобы изменения в продукте или системе вводились контролируемым и скоординированным образом. Он снижает вероятность того, что ненужные изменения будут введены в систему без предварительной подготовки, что приведет к сбоям в работе системы или отмене изменений, внесенных другими пользователями программного обеспечения. Цели процедуры контроля изменений обычно включают минимальное нарушение работы служб, сокращение числа откатов и экономически эффективное использование ресурсов, задействованных в реализации изменений. Согласно Институту управления проектами , контроль изменений — это «процесс, посредством которого изменения в документах, результатах или базовых показателях, связанных с проектом, определяются, документируются, утверждаются или отклоняются». [2]
Контроль изменений используется в различных отраслях, включая ИТ, [3] разработку программного обеспечения, [1] фармацевтическую промышленность, [4] производство медицинских приборов, [5] и другие отрасли машиностроения/производства. [6] Для отраслей ИТ и программного обеспечения контроль изменений является основным аспектом более широкой дисциплины управления изменениями. Типичными примерами из компьютерных и сетевых сред являются исправления для программных продуктов, установка новых операционных систем , обновления таблиц сетевой маршрутизации или изменения в системах электропитания , поддерживающих такую инфраструктуру . [1] [3]
Определенные части ITIL охватывают контроль изменений. [7]
Существует значительное совпадение и путаница между управлением изменениями , управлением конфигурациями и контролем изменений. Определение ниже еще не интегрировано с определениями других.
Контроль изменений можно описать как набор из шести шагов:
Рассмотрите основные и вспомогательные детали предлагаемого изменения. Это должно включать такие аспекты, как определение изменения, его владельца(ей), как оно будет сообщено и выполнено, [8] как будет проверен успех, оценка важности изменения, его добавленная стоимость, его соответствие деловым и отраслевым стандартам и его целевая дата завершения. [3] [9] [10]
Оценка воздействия и риска — это следующий важный шаг. При выполнении предложенный план может привести к чему-то неправильному? Повлияет ли предлагаемое изменение на связанные системы? На этом этапе следует учитывать даже незначительные детали. После этого в идеале следует назначить категорию риска предлагаемому изменению: высокий, средний или низкий риск. Высокорисковые изменения требуют множества дополнительных шагов, таких как одобрение руководства и уведомление заинтересованных сторон, тогда как низкорисковые изменения могут потребовать только одобрения менеджера проекта и минимальной документации. [3] [9] [10] Если это не предусмотрено планом/областью действия, следует выразить желание иметь план отката, особенно для высокорисковых изменений, которые имеют существенные наихудшие сценарии. [3]
Независимо от того, является ли это контроллером изменений, советом по контролю изменений , руководящим комитетом или менеджером проекта, обычно требуется процесс рассмотрения и утверждения. [11] План/область действия и оценки воздействия/риска рассматриваются в контексте бизнес-целей, требований и ресурсов. Если, например, считается, что запрос на изменение касается проблемы с низкой степенью серьезности и низким воздействием, для исправления которой требуются значительные ресурсы, запрос может быть отнесен к низкоприоритетным или вообще отложен. В случаях, когда запрашивается изменение с высоким воздействием, но без четкого плана, субъект рассмотрения/утверждения может запросить полное бизнес-обоснование для дальнейшего анализа. [1] [3] [9] [10]
Если запрос на управление изменениями одобрен для продвижения вперед, группа доставки выполнит решение через процесс разработки небольшого масштаба в тестовых или девелоперских средах. Это дает группе доставки возможность проектировать и вносить постепенные изменения с помощью модульного и/или регрессионного тестирования . [1] [3] [9] Для изменений с низким уровнем риска может потребоваться немного тестирования и проверки, хотя серьезные изменения потребуют значительного тестирования перед внедрением. [9] Затем они будут добиваться одобрения и запрашивать время и дату для выполнения фазы внедрения. В редких случаях, когда решение невозможно протестировать, следует уделить особое внимание окну изменения/внедрения. [3]
В большинстве случаев для внедрения изменения используется специальная группа по внедрению с техническими знаниями для быстрого продвижения изменения. Группа должна также внедрять изменение не только в соответствии с утвержденным планом, но и в соответствии с организационными стандартами, отраслевыми стандартами и стандартами управления качеством. [9] Процесс внедрения может также потребовать дополнительных обязанностей персонала за пределами группы внедрения, включая заинтересованные стороны [11], которых могут попросить помочь с устранением неполадок. [3] После внедрения группа может также провести обзор после внедрения, который будет проходить на другой встрече заинтересованных сторон или во время процедур закрытия проекта. [1] [9]
Процесс закрытия может быть одним из наиболее сложных и важных этапов контроля изменений. [12] Три основные задачи на этом конечном этапе включают определение того, что проект фактически завершен, оценку «плана проекта в контексте завершения проекта» и предоставление ощутимого доказательства успешности проекта. [12] Если, несмотря на все усилия, что-то пошло не так в процессе контроля изменений, необходимо провести вскрытие того, что произошло, с целью применения извлеченных уроков к будущим изменениям. [3]
В отрасли, регулируемой надлежащей производственной практикой , эта тема часто встречается у ее пользователей. Различные промышленные руководства и комментарии доступны для понимания этой концепции. [13] [14] [15] Как правило, деятельность обычно направляется одним или несколькими стандартными операционными процедурами . [16] С точки зрения информационных технологий для клинических испытаний она направляется другим документом Управления по контролю за продуктами питания и лекарственными средствами США . [17]
{{cite book}}
: CS1 maint: отсутствует местоположение издателя ( ссылка )