Изменение контроля
В системах управления качеством (СМК) и системах информационных технологий (ИТ) контроль изменений представляет собой процесс — формальный или неформальный. [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]
См. также [ править ]
- Запрос на изменение
- Изменить порядок
- Порядок внесения инженерных изменений
- Документация
- Идентификатор
- Контроль версий
- Журнал изменений
- Живой документ
- Спецификация (технический стандарт)
- Стандартизация
- Управление объемом
Цитаты [ править ]
- ^ Jump up to: а б с д и ж Холл, ПАВ; Рамиль, JCF (2007). Управление предприятием, производящим программное обеспечение: программная инженерия и информационные системы в контексте . Cengage Обучение. стр. 318–325. ISBN 9781844803545 . Проверено 20 мая 2018 г.
- ^ Институт управления проектами 2021 , Глоссарий §3 Определения.
- ^ Jump up to: а б с д и ж г час я дж Маттесон, С. (7 июля 2017 г.). «10 основных элементов управления контролем изменений» . Техреспублика . CBS Interactive, Inc. Проверено 20 мая 2018 г.
- ^ Тернер, SG (15 декабря 2003 г.). Управление изменениями в фармацевтической инженерии . Тейлор и Фрэнсис. стр. 200 . ISBN 9780849320613 .
- ^ Тейшейра, МБ (2013). Средства контроля проектирования для промышленности медицинского оборудования (2-е изд.). ЦРК Пресс. п. 205. ИСБН 9781466503557 .
- ^ Монаханм Э. (1995). Практика и процедуры контроля инженерной документации . ЦРК Пресс. п. 280. ИСБН 9780824795740 .
- ^ Герциг, ТВ; Уолш, Т.; Галлахер, Луизиана (2013). Внедрение информационной безопасности в здравоохранении: построение программы безопасности . Общество информации и систем управления здравоохранением. стр. 204–205. ISBN 9781938904356 . Проверено 20 мая 2018 г.
- ^ Институт управления проектами 2021 , §4.6.3 Встречи и мероприятия.
- ^ Jump up to: а б с д и ж г Тейлор, Дж. (2008). Планирование проекта и контроль затрат: планирование, мониторинг и контроль базового плана . Издательство Дж. Росс. стр. 192–203. ISBN 9781932159110 . Проверено 20 мая 2018 г.
- ^ Jump up to: а б с Офис программы операционного совершенствования. «Процесс контроля изменений» (PDF) . Калифорнийский университет в Беркли . Проверено 20 мая 2018 г.
- ^ Jump up to: а б Институт управления проектами 2021 , §4.4.3 Встречи и мероприятия.
- ^ Jump up to: а б Тейлор, Дж. (2008). «Глава 11: Успешное закрытие проекта» . Планирование проекта и контроль затрат: планирование, мониторинг и контроль базового плана . Издательство Дж. Росс. стр. 215–225. ISBN 9781932159110 . Проверено 20 мая 2018 г.
- ^ «Руководство для промышленности: системный подход к фармацевтическим правилам CGMP» (PDF) . Управление по контролю за продуктами и лекарствами США . Сентябрь 2006 года . Проверено 12 июля 2009 г.
- ^ Настой. «Проблемы контроля изменений в регулируемой отрасли» (PDF) . Проверено 28 апреля 2009 г. [ постоянная мертвая ссылка ]
- ^ ИЧ . «Q7: Руководство по надлежащей производственной практике активных фармацевтических ингредиентов» (PDF) . Проверено 20 апреля 2011 г.
- ^ Онлайн-консультация GMP. «Система контроля изменений: стандартная операционная процедура» . Проверено 28 апреля 2009 г.
- ^ «Руководство для промышленности – КОМПЬЮТЕРИЗОВАННЫЕ СИСТЕМЫ, ИСПОЛЬЗУЕМЫЕ В КЛИНИЧЕСКИХ ИССЛЕДОВАНИЯХ» . Управление по контролю за продуктами и лекарствами США . Апрель 1999 года . Проверено 13 мая 2021 г.
Ссылки [ править ]
- Институт управления проектами (2021). Руководство по совокупности знаний по управлению проектами (руководство PMBOK) . Институт управления проектами (7-е изд.). Ньютаун-сквер, Пенсильвания. ISBN 978-1-62825-664-2 .
{{cite book}}: CS1 maint: отсутствует местоположение издателя ( ссылка )