 |
Good Automated Manufacturing Practice
Pharmaceutical Industry Supplier Guide for Validation of Automated Systems
in Pharmaceutical Manufacture
Надлежащая практика автоматизированного производства
Руководство для поставщиков фармацевтической промышленности по валидации автоматизированных систем для фармацевтической промышленности
ПРИЛОЖЕНИЕ A:
Процедура составления Спецификации требований пользователя
Ответственный: Заказчик
1. Введение
Здесь описываются стандарты по написанию и содержанию Спецификации требований пользователя (User Requirements Specifications (URS).
2. Применение
Эта методика может использоваться производителями фармацевтической продукции или лицами, работающими от их имени, для того, чтобы определить требования к автоматизированной системе. URS представляется поставщику и рассматривается как конечное требование к тому, что должна делать система.
3. Процедура
3.1. Общие указания
Спецификация требований пользователя четко определяет, что заказчик хочет видеть в системе: какие функции он должна выполнять, на каких данных будет работать, в какой операционной среде. URS также определяет любые неконструктивные требования, ограничения, такие как сроки выполнения работ, цена, какие комплектующие должны быть поставлены и т.д. Упор должен делаться на те функции, которые должна выполнять система по окончанию работы, а не на то, как будут внедряться эти функции програмистами.
При составлении спецификации необходимо учесть следующее:
1. Каждое требование должно быть четко описано, если требуется с применением схем, таблиц, и не должно превышать 250 слов.
2. Требования не должны повторяться или противоречить друг другу.
3. URS должна содержать требования к программе, а не предлагать решения.
4. Каждое требование должно быть контролепригодным, т.е. должна предусматриваться возможность его тестирования.
5. URS должна быть понятна как заказчику, так и исполнителю, необходимо избегать любых двусмысленностей или жаргона.
6. При возможности URS должна различать требования, обязательные к исполнению, и желательные.
7. Возможно, потребуется официальное рассмотрение URS заказчиком и исполнителем. Это поможет проверить понимание требований URS, а также проверить учтены ли (или нет) требования URS в Функциональной Спецификации (Functional Specification).
3.2. Содержание документа
Данный раздел определяет какие разделы и подразделы должны быть включены в URS. Все нижеперечисленные разделы должны быть включены. Если требования по данному разделу не определены, он помечается как 'Not applicable' («Не применяется»).
3.2.1. Введение
Данный раздел содержит следующую информацию:
1. Кто составил документ, на каком основании и с какой целью.
2. Договорной статус документа (контракт, договор, обязательство, соглашение).
3. Связь с другими документами.
3.2.2. Общее представление о системе
Данные раздел описывает систему в общих чертах, объясняя, для чего она необходима и что от нее требуется. Раздел содержит следующие подразделы:
1. Предпосылки для создания системы (например, корпоративная стратегия, предшествующие исследования).
2. Основные цели создания системы и преимущества ее использования.
3. Главные функции системы и интрефейсы.
3.2.3. Операционные требования
Данный раздел оговаривает операционные требования – структурные функции системы, данные, интерфейс и операционную среду. Критические требования должны быть подчеркнуты и определены как таковые.
Должны быть включены следующие подразделы:
3.2.3.1. Функции
Подраздел определяет системные функции, режимы работы и поведение системы. Он должен описывать следующее:
- необходимые функции. Сюда должна быть включена информация по процессу производства или существующей неавтоматической системе, если только это не оговаривалось выше.
- рассчеты, включая все решающие алгоритмы.
- режимы работы (например, запуск, закрытие системы, тестирование, нейтрализация неисправностей).
- Требования к быстродействию и синхронизации. Должны быть количественными и точно выраженными.
- Выход из строя. Какие действия необходимы в случае, если программа или аппаратные средства вышли из строя.
- надежность и безопасность.
3.2.3.2. Данные
Этот раздел рассматривает требования к обработке данных. Он должен описывать следующее:
- Определение данных. При этом оговариваются их критические параметры.
- Требования по пропускной способности.
- Требования по скорости доступа.
- Требования к архивированию.
3.2.3.3. Интерфейсы
Раздел определяет возможные интерфейсы системы. Включает следующие подразделы:
1. Интерфейс с пользователями – описываются для каждой роли (например, оператор, администратор склада, менеджер системы и т.д.) и/или функций в зависимости от обстоятельств.
2. Интерфейс с другими системами.
3. Интерфейс с оборудованием (например, сенсоры/приводы).
3.2.3.4. Окружающая среда
Раздел определяет в какой среде будет работать система. Включает следующие подразделы:
1. Размещение. Физическое расположение оборудования или рабочего места может влиять на работу системы (например, связи на больших расстояниях, ограниченная площадь).
2. Физические условия (например, пыльное или стерильное помещение и т.д.).
3.2.4. Ограничения
Раздел определяет ограничения на спецификацию системы. Должен содержать следующие подразделы:
1. Временные рамки.
2. Совместимость. Должна учитываться совместимость с любыми существующими системами или оборудованием, а также с любыми возможными стратегиями развития компании.
3. Возможность использования. Оговариваются требования к надежности системы и максимально допустимые сроки текущего ремонта или иного простоя.
4. Процедурные ограничения (например, обязательства перед законом или уставом, возражения правового порядка, методы работы или уровень квалификации пользователей).
5. Сопровождение (например, легкость обслуживания, возможность наращивания, модернизации, ожидаемый срок службы, долгосрочная поддержка).
3.2.5. Жизненный цикл
Раздел устанавливает сроки разработки системы. Содержит следующие подразделы:
1. Разработка (например, порядок управления проектом и гарантии качества, обязательные методы разработки).
2. Тестирование (например, особые требования к тестированию, данные для тестирования, испытание под нагрузкой – тестирование загрузки, имитационное тестирование).
3. Поставка. Определяет, что должно быть доставлено. Сюда относится следующее:
- Как идентифицируются доставляемые элементы.
- В какой виде они поставляются (например, формат и носители).
- Документы. Какие документы должен предоставить поставщик (например, функциональная спецификация (functional specification), спецификации тестирования (testing specifications), проектные спецификации (design specifications) и т.д.).
- Данные, которые должны быть подготовлены или конвертированы.
- Инструменты.
- Тренинги.
- Оборудование для архивирования.
4. Сопровождение. Раздел описывает, какая поддержка необходима будет после принятия программы.
3.2.5. Глоссарий
Раздел содержит разъяснения терминов, которые могут быть незнакомы читающему URS.
4. Ссылки
Ссылок нет.
ПРИЛОЖЕНИЕ B:
Процедура анализа документации и ПО
Ответственный: Заказчик и Поставщик
1. Введение
Данная процедура описывает методику проведения, регистрации и контроля за исполнением:
- Анализа официальной документации;
- Анализа програмной части приложения (иногда называют «анализ кода программы»).
2. Применение
Данная методика применяется к документации и програмному обеспечению, представляемым поставщиком в соответствии с Планом качества.
3. Процедура
3.1. Анализ документации
Анализ документации проводится до официального написания документа.
Анализ проводится официально, при этом составляется протокол на основе Отчета о проверке (Review Report) [1].
Анализ проводят лица, утвержденные планом или назначенные менеджерами высшего звена.
Копии документа, представленного на анализ, должны быть распространены заранее, что позволит обеспечить надлежащую подготовку.
Во время работы должен быть систематически проанализирован каждый раздел документа. Если раздел принят без комментариев, это должно быть зафиксировано в протоколе.
Кому направить официальный документ согласовывается членами комиссии и вносится в протокол [1].
Коррективы, намеченные в ходе анализа, выполняются согласно раздела «Дальнейшая доработка» (Follow-up).
И только когда все изменения, предложенные комиссией, будут внесены в окончательную версию документа, документ может быть подписан. Первоначальная версия документа должна сохраняться.
Все отчеты о проверке (Review Reports) должны быть зарегистрированы и снабжены указателем согласно Сводке отчетов (Review Summary) [2].
3.2. Анализ програмной части приложения
Анализ прикладного програмного обеспечения проводится лицами, утвержденными планом. Желательно включить разработчика или автора ПО.
Анализ ПО должен проводиться официально и быть запротоколирован на основе Отчета о проверке [1].
Должны быть рассмотрены следующие аспекты:
- Схема ПО.
- Соблюдение стандартов кодирования.
- Логика ПО.
- Избыточный код.
- Важнейшие алгоритмы (согласно Спецификации требований пользователя).
Согласованные изменения, необходимость которых вытекает из анализа ПО, выполняются согласно раздела «Дальнейшая доработка» (Follow-up) данной методики.
Все изменения должны быть внесены до сдачи ПО.
Все отчеты о проверке должны быть зарегистрированы и снабжены указателем согласно Сводке отчетов [2].
Распечатки, структурные схемы и т.д. должны сохраняться вместе с отчетом о проверке.
3.3. Устранение замечаний, выявленных в ходе проверки
На каждое внесение изменений назначается ответственный, который должен закончить работу к утвержденной дате. По окончанию работы все замечания о том, как вносились измения, фиксируются в [1], и работа считается оконченной. Когда внесены все изменения, отчет закрывается. Сводка отчетов [2] корректируется с учетом внесенных поравок.
Отчеты о проверке [1] и сводки отчетов [2] периодически проверяются руководителем проекта. Если изменения внесены не так, как намечалось, или нет записей о выполнении работы, руководитель проекта принимает меры.
3.4. Общие положения
Спецификации по проектированию модулей ПО (Software Module Design Specifications) скорее относятся к анализу ПО, нежели к анализу документации, при условии, что они пишутся с использованием логических диагарам или псевдо-кода. Если же эта спецификация пишется в виде текста, тогда она относится к анализу документации.
4. Ссылки
[1 ] Форма 9, ПРИЛОЖЕНИЕ R - Отчет о проверке (Review Report)
[2] Форма 10, ПРИЛОЖЕНИЕ R – Сводка отчетов (Review Summary)
ПРИЛОЖЕНИЕ C:
Процедура проведения аудита поставщика
Ответственный: Заказчик
1. Введение
Данная методика описывает процесс проверки заказчиком поставщиков програмного обеспечения: его планирование, выполнение и внесение изменений.
2. Применение
Данная методика применяется при проведении внешнего аудита поставщиков автоматизированных систем, что является частью формальной системы оценивания поставщиков, согласно Плана валидации (Customer Validation Plan).
3. Процедура
3.1. Аудиторы
Аудиторами назначают работников, имеющих, по мнению руководителй проекта, достаточный опыт и квалификацию.
3.2. Планирование аудита
В ходе общего процесса валидации автоматизированной системы, заказчик должен убедиться, что поставщик в состоянии выполнить все требования, зафиксированные в Плане валидации данной системы. Для этого может понадобиться внешний контроль качества.
Заказчик хранит все документы по аудиту и на основе полученных данных делает рекомендации в соответствии с разделом 3.5 данной процедуры.
Заказчик придерживается Плана внешнего контроля качества (External Quality Audit Schedule), который определяет, как часто будут проводиться такие проверки. Частота проверок зависит от нескольких факторов: насколько качественно был выполнен заказ в предыдущий раз (исходя из предыдущих аудитов), как часто фирма-заказчик работала с данным поставщиком и т.д.
Необходимо помнить, что даже если данная Система качества (Quality System) поставщика зарегистрирована согласно национальному или международному Стандарту качества (например, ISO 9000), регулярные плановые проверки необходимы.
3.3. Подготовка и проведение аудита
Аудиты могут проводиться и документироваться согласно инструкции, изложенной в ISO 10011 Часть 1. При проведении аудита используется приведенная ниже контрольная таблица (checklist).
3.4. Завершение аудита
Отчеты о проведении аудита хранятся в составе общей документации по проекту.
После получения отчета о проведении аудита, заказчик принимает одно из нижеизложенных решений:
- одобрить поставщика без условий
- одобрить поставщика после того, как будут внесены изменения, предписанные Отчетом по внешнему аудиту качества (External Quality Audit Report)
- согласовать документацию Системы качества (Quality System) с поставщиком в контрактных целях
- запретить работу с поставщиком.
3.5. Внесение исправлений, доработка и надзор
Если в ходе аудита поставщика обязывают выполнить определенные изменения, аудиторы контролируют этот процесс и составляют документ, подтверждающий, что все изменения были внесены, после чего работы по контракту продолжаются.
В отчете о проведении внешнего аудита качества также определяются частота контрольных визитов и план дальнейших проверок.
4. Ссылки
[1] IS010011 Part 1 Guidelines for Quality Systems Auditing
или
BS7229 British Standards Guide to Quality Systems Auditing
[2] ISO 9000 Quality Systems
или
BS5750 British Standards Quality Systems
5. Контрольная таблица
Ниже приводится контрольная таблица для проведения аудита поставщиков автоматизированных систем. Она содержит лишь основные пункты, в то время как в каждом конкретном случае может потребоваться проверка иных, дополнительных факторов.
5.1. Организация
- Структура менеджмента (роли, ответственность, позиция при проведении аудита (QA)
- Политика компании
- Документация по системе управления качеством (руководство (Manual), процедуры (Procedures)
- Любой признанный сертификат качества.
5.2. Планирование
- Проверки контракта
- План проекта//качества (временные рамки, жизненный цикл, мероприятия, персонал, ограничения, проверка
- Мониторинг проекта
- Документация по проверкам
- Записи по проекту.
5.3. Спецификация
- Спецификация требований пользователя (User Requirements Specification)
- Функциональная спецификация (Functional Specification)
- Спецификации разработки ПО (Software Design Specifications)
- Спецификации проектирования аппаратных средств (Hardware Design Specifications)
- Документация о проверках (Documented Reviews)
- Используемая методология проектирования (Design Methodologies Used)
- Метрики производительности програмиста/аналитика.
5.4. Внедрение
- Исходный код (доступный, структурированный, хорошо документированный)
- Документация по проверкам исходного кода.
5.5. Тестирование
- ПО для тестирования/Тестовые данных/Симуляторы
- Спецификации тестирования ПО
- Результаты тестирования ПО
- Спецификация тестирования аппаратных средств
- Результаты тестирования аппаратных средств
- Спецификация приемочного тестирования системы (на территории разработчика, на месте)
- Результаты тестирования системы.
- Документация по проверкам.
5.6. Завершение
- Передача материалов проекта (сертификаты соответствия, гарантии)
- Документация для пользователей
- Поддержка.
5.7. Мероприятия по контролю
- Управление документацией
- Управление конфигурацией ПО (Контроль ПО)
- Контроль изменений (документация, ПО)
- Управление системой (доступ, безопасность, резервное копирование, инструменты ПО)
- Архивация
- Субконтрактный контроль
- Внутренние проверки (аудиты)
- Что приобретено
- Обучение персонала
- Поддержка.
ПРИЛОЖЕНИЕ D:
Процедура производства, контроля и выпуска програмного обеспечения.
Ответственный: Поставщик
1. Введение
Данный документ определяет позицию менеджмента проекта, стандарты программирования ПО и методику контроля за конфигурацией.
2. Применение
Данная методика применяется ко всему ПО, разрабатываему в рамках данного проекта. Если проект не согласован с данной процедурой, или есть отклонения, это должно быть отмечено в Плане качества [1].
3. Процедура
3.1. Производство ПО
В любом проекте в первую очередь определяются стандраты кодирования, которых и придерживаются в ходе програмирования. Соглашения по кодированию должны включать комментарии и схемы. Все это документируется, например, в описании проекта (project note) с соответствующими ссылками в Плане качества.
В каждом проекте устанавливаются свои стандарты по присваиванию имен директориям и файлам, и это также обязательно документируется с соответствующими ссылками в Плане качества.
Где это необходимо, создается также набор командных файлов для управления конструкцией, а именно для:
- Компилирования исходных модулей ПО
- Компоновки конечных модулей ПО
- Запуска исполнимых изображений.
Командные файлы должны быть достаточно общими, так чтобы все члены команды могли их использовать.
После того, как программный код будет создан и успешно компилирован, он должен быть подвергнут критическому анализу согласно [2]. Критический разбор программы производится перед приемочным тестированием ПО.
3.2. Контроль за конфигурацией
В каждом проекте должна быть разработана методика контроля за ПО с тем, чтобы обновления к замороженному ПО обрабатывались последовательно и контролировались надлежащим образом. Контроль за конфигурацией ПО осуществляется в соответствии с Планом управления конфигурацией (Configuration Management Plan).
3.3. План управления конфигурацией
План управления конфигурацией составляется для любых проектов по ПО и является частью Плана качества.
План управления конфигурацией включает следующие пункты:
- Организация и распределение ответственностей с соответствующими ссылками в Плане качества.
- Мероприятия по управлению конфигурацией, см. ниже.
- Используемые методы управления конфигурацией.
- Указание на то, на какой стадии работы каждый элемент будет подвергаться контролю конфигурации ПО.
3.3.1. Мероприятия по управлению конфигурацией
- Идентификация конфигурации и трассируемость.
Каждый элемент ПО должен иметь уникальный идентификационный номер/имя.
Номер/имя должны быть такими, чтобы была возможность отследить код до следующего, верхнего, уровня таким образом, чтобы все элементы ПО можно было отследить по соответствующим спецификациям либо по нумерации/именам, либо по соответствующему тексту в заголовке модуля.
Соглашение по нумерации/именованию должно быть четко описано.
- Контроль изменений
Изменения контролируются согласно [3].
Все запросы на внесение изменений должны быть зарегистированы, например, в форме заявки на внесение изменений, описанной в [3], которая хранится в соответствующем «Реестре заявок на внесение изменений».
- Отчет о состоянии конфигурации (Configuration status report)
Конфигурация ПО и ее состояние должны определяться для каждого проекта, например, в виде списка, в котором будут указаны номер версии и соответсвующие запросы на внесение изменение.
3.4. Идентификация и трассируемость модулей ПО
3.4.1. Идентификация модулей ПО
Каждый модуль ПО в своем заголовке/шапке должен обязательно содержать следующую информацию:
- Название/имя модуля
- Названия/имена составляющих исходных файлов
- Номер версии модуля
- Название и номер проекта (если есть)
- Караткое описание модуля
- Все коммандные файлы, используемиые для компилирования и компоновки модуля
- История изменений. Описание каждого изменения должно содержать следующую информацию:
Номер заявки на внесение изменений
Номер новой версии
Дата внесения изменения (изменений)
Инициалы человека (людей), вносившего изменения
Исходный файл (файлы), которые подвергались изменениям.
3.4.2. Трассируемость модуля ПО
Все изменения модулей ПО должны быть четко описаны в исходных файлах кодирования.
Добавления описываются через использование комментария, который ссылается на соответствующий номер Заявки на внесение изменений (Change Request).
Удаления могут описываться двумя способами:
- Комментирование кода и обозначение удаления через ссылку на соответствующий Запрос на внесение изменений
или
- Удаление кода и обозначение удаления через ссылку на соответствующий Запрос на внесение изменений.
4. Ссылки
[1 ] ПРИЛОЖЕНИЕ G - План качества и план проекта (Quality and Project Plan)
[2] ПРИЛОЖЕНИЕ B - Отчеты по документации и ПО (Document and Software Reviews)
[3] ПРИЛОЖЕНИЕ F - Контроль изменений (Change Control)
ПРИЛОЖЕНИЕ E:
Процедура составления, контроля и выпуска документации
Ответственный: Поставщик
1. Введение
Данная методика описывает систему подготовки, анализа, утверждения и непосредственного выпуска документов.
2. Применение
Эта процедура применяется к документации по проекту так, как это предусмотрено Планом качества поставщика.
3. Процедура
3.1 Составление документации
Стандарты по составлению документации согласовываются на месте. Сюда входит порядок оформления документов, стиль и нумерация. Все документы составляются в соответствии с принятой процедурой. Заверяющие подписи в каждом документе должны сопровождаться указанием должностей лиц, подписыващих документ.
До того, как документ будет принят окончательно, составляется предварительный набросок, которому присвивается номер/имя (например, в алфавитном порядке, начиная с А, с последующем номером версии).
До официального рассмотрения документа за него отвечает составитель.
3.2 Анализ документа и утверждение
Вся документация подвергается официальному рассмотрению согласно [7].
При анализе документа открывается так называемая История документа (Document History) [1], которая хранится в Главном архиве документов (Master Document File) в соответствии с разделом 3.6 данной процедуры.
После внесения изменений, необходимость которых показал разбор документа, документ переходит в следующую стадию разработки.
Подписи согласования, необходимые данному документу или затребованные руководством, ставятся с использованием [3]. Официальные подписи в конце документа ставят два или более ответственных сотрудника.
Подписи согласования подтверждают со всей ответственностью, что документ был тщательно изучен лицом, подписавшим его.
Дальнейшие изменения вносятся в соответствии с разделом 3.5 данной процедуры.
Официально рассмотренная копия черновика документа и отчет о рассмотрении хранится в соответсвии с разделом 3.7 данной процедуры.
3.3 Выпуск документа
Согласованные документы издаются и хранятся в соответствующих папках, как это определено Протоколом хранения документации (Document Review Minutes) [7] или непосредственно руководством.
После выпуска документа необходимо:
- Обновить Историю документа [1]
- Обновить индекс документов
- Открыть/обновить Журнал циркуляции документа (Document Circulation Register) [4]
- Создать запись о передаче документа (Document Transmittal Notice) [5] для каждой контролируемой копии
- Написать номер копии на документе
Копия записки о передаче документа (Document Transmittal Notices) [5] хранится до тех пор, пока не вернется подписанный оригинал.
Вышеупомянутые записи хранятся в Главном архиве документов в соответствии с разделом 3.6 данной процедуры.
Замененная документация хранится в Папке архивной документации (Archive Document File) в соответствии с разделом 3.7 данной процедуры.
Неконтролируемые копии должны быть четко обозначены пометкой 'UNCONTROLLED' («неконтролируемый»).
Изменения в Реестре циркуляции документа [4] должны быть сначала согласованы с руководством. Далее контролируемые копии выпускаются в соответствии с пунктами 3, 4 и 5 выше.
3.4 Аннулирование документов
Документы могут быть аннулированы только по получении соответствующего заявки на внесение изменений, заверенного подписями согласования. Процедура аннулирования такова:
- Обновить главный индекс (Master Index), присвоив документу статус 'WITHDRAWN' («аннулирован»)
- Обновить Историю документа [1]
- Создать записи о передаче [5] согласно Журналу распространения документа [4] с указанием всем держателям копий документа уничтожить их.
- Архивизировать документацию в соответствии с разделом 3.7 данной процедуры.
3.5 Внесение изменений в документы
Процесс внесения изменений в документы проходит в соответствии с [2]. Документ переходит в следующую стадию разработки и переиздается в соответствии с разделом 3.3. данной процедуры.
Внесение значительных изменений или переписывание документа осуществляется следующим образом:
- Перевести документ в разряд черновика (например, Draft 3A)
- Выполнить указания разделов 3.1, 3.2 и 3.3 данной процедуры.
3.6 Главный архив документов
Необходимо постоянно поддерживать в рабочем состоянии Главный архив документов.
Для каждого документа хранятся:
- Оригинал/основной экземпляр документа
- История документа [1].
Для официально изданных документов также хранятся:
- Согласование/одобрение документа (Document Approval) [3] или Заявки на внесение изменений (Change Requests) [8]
- Журнал циркуляции документа (Document Circulation Register) [4]
- Запись о передаче документа (Document Transmittal Notices) [5].
Также хранится Реестр основных документов, который включает:
- Идентификационный номер документа
- Заголовок документа
- Статус документа.
3.7 Папка архивных документов
Замененные и аннулированные документы хранятся в отдельной папке с соответствующим названием.
Каждый документ должен быть четко обозначен пометками «Заменен» ('SUPERSEDED') или «Аннулирован» ('WITHDRAWN').
Отчеты о рассмотрении документа сохраняются и для черновых документов.
Для каждого официально выпущенного документа сохраняются:
- Согласование/одобрение документа (Document Approval) [3] или Заявки на внесение изменений (Change Requests) [8]
- Журнал циркуляции документа (Document Circulation Register) [4]
- Записи о передаче документов (Document Transmittal Notices) [5].
Каталог/регистр архивных документов сохраняется с использованием [6].
4. Ссылки
[1 ] Форма 4, ПРИЛОЖЕНИЕ R – История документа (Document History)
[2] ПРИЛОЖЕНИЕ F –Процедура контроля за внесением изменений (Procedure for Change Control)
[3] Форм 1, ПРИЛОЖЕНИЕ R – Согласование документа (Document Approval)
[4] Форм 2, ПРИЛОЖЕНИЕ R – Журнал циркуляции документа (Document Circulation Register)
[5] Форм 3, ПРИЛОЖЕНИЕ R – Запись о передаче документа (Document Transmittal Notice)
[6] Форм 5, ПРИЛОЖЕНИЕ R – Каталог архивных документов (Archived Document Index)
[7] ПРИЛОЖЕНИЕ B –Процедура анализа документации и ПО (Procedure for Document and Software Review)
[8] Форм 6, ПРИЛОЖЕНИЕ R – Заявка на внесение изменений (Change Request)
ПРИЛОЖЕНИЕ F:
Процедура контроля за внесением изменений
Ответственный: Заказчик и Поставщик
1. Введение
Данная процедура описывает систему контроля за внесением изменений в автоматизированную систему.
Контроль за внесением изменений необходим для того, чтобы придерживаться утвержденных методов работы и продукта.
2. Применение
Эта процедура применяется к изменениям, вносимым в документацию, в прикладное ПО, ПО операционной системы, во встроенные программы, аппаратные средства и конфигурацию системы, где на это есть ссылки в Плане качества поставщика.
Замещение элементов равнозначными, например, в следствие сбоя в работе аппаратных средств, относится к эксплуатации системы и поэтому не подлежит контролю за внесеним изменений, описываемому в данном разделе.
3. Процедура
3.1. Общие положения
Все изменения должны быть санкционированы, задокументированы, протестированы и одобрены до начала их внедрения.
Однако, есть исключения:
- Аварийный ремонт
- Изменения, проводимые во время согласованной экспериментальной работы
Все изменения, вытекающие из вышеупомянутых случаев, должны быть позднее проанализированы, протестированы, задокументированы и одобрены в соответствии с данной процедурой.
3.2. Запрос на внесение изменений
Когда есть необходимость внести изменения, в форме Заявки на внесение изменений [1] заполняется раздел Запрос о внесении изменений (REQUEST FOR CHANGE). Каждому запросу на внесение изменений присваивается уникальный номер, который регистрируется с использованием [2].
3.3. Санкционирование внесения изменений
Для каждой системы назначается менеджер проекта, который и является ответственным за то, чтобы все изменения в систему вносились надлежащим образом. Менеджер проекта может также делегировать данные полномчия.
Каждая заявка на внесение изменений рассматривается руководством с вынесением соответствующего распоряжения: принять/отклонить. Обычно это решение не принимается единолично – необходимо, по крайней мере, два человека. Те элементы, которые ранее были одобрены фармацевтической фирмой-заказчиком (например, контрактные документы, протестированное и принятое ПО) могут быть изменены только после согласования с заказчиком.
3.3.1. Отклоненные изменения
Лица, принявшие решение об отклонении Заявки на внесение изменений, заполняют и подписывают раздел «Санкционирование внесения изменения» (Change Disposition and Authorisation) Заявки, указывая причины для ее отклонения в разделе «Детали изменеия» (Сhange Details).
Заявка на внесение изменений должна быть зарегистрирована, Каталог [2] обновлен, а заявитель информирован о принятом решении.
3.3.2. Принятые изменения
Лица, принявшие решение о принятии Заявки на внесение изменений, заполняют и подписывают раздел «Санкционирование внесения изменения» Заявки. Также они определяют:
- Какие контролируемые элементы подвергаются действию Заявки
- Какие тесты необходимы для того, чтобы убедиться, что рабочие характеристики не изменились.
Эти решения записываются в разделе «Детали изменений» Заявки.
Если более одного контролируемого элемента будет подвергнуто изменению согласно данной Заявки, Уведомление о внесении изменений (Change Note) [3] составляется для каждого элемента, определяя какие именно изменения будут внесены в каждый элемент.
Для сложных работ может потребоваться План внесения изменений, который прилагается к Заявке на внесение изменений, которая в свою очередь должна быть снабжена соответствующей ссылкой.
3.4. Завершение процесса внесения изменений и его утверждение
Когда все изменения внесены и их тестирование закончено, Заявка на внесение изменений передается руководству для окончательного рассмотрения и утверждения.
Заполненная заявка на внесение изменений архивируется, а Каталог [2] обновляется.
4. Ссылки
[1] ПРИЛОЖЕНИЕ R, Форма 6 – Заявка на внесение изменений (Change Request)
[2] ПРИЛОЖЕНИЕ R, Форма 12 – Реестр заявок на внесение изменений (Change Request Index)
[3] ПРИЛОЖЕНИЕ R, Форма 13 - Уведомление о внесении изменений (Change Note)
ПРИЛОЖЕНИЕ G:
Процедура составления Плана качества и Плана проекта
Ответственный: Поставщик
1. Введение
Данное приложение описывает процедуру составления Планов качества для индивидуальных проектов.
План качества/проекта определяет, как поставщик будет выполнять требования заказчика по качеству, какие работы будет проводиться, их сроки, исполнители, а также механизмы контроля.
2. Применение
Данная процедура используется для построения Планов качества/Планов проектов для всех проектов поставщика по программированию.
3. Процедура
3.1. Содержание документа
Далее идет описание, какие разделы и подразделы включаются в План качества/План проекта. Все заголовки разделов и подразделов должны обязательно присутствовать. Если раздел не рассматривается, ставится пометка «Не применяется к данному контракту/договору» ('Not applicable to this contract').
План качества/План проекта – это контрактный документ и, следовательно, должен быть одобрен менеджером по обеспечению качества изделий поставщика (или представителем), менеджером проекта со стороны поставщика и заказчиком.
3.2. Раздел «Введение»
Содержит следующую информацию:
- Кто составил документ, на каких полномочиях, с какой целью.
- Контрактный статус документа.
- Связь с GAMP, если есть.
- Связь с Планом валидации, если есть.
3.3. Раздел «Общие сведения»
Данный раздел вкратце описывает проект.
3.4. Раздел «План качества»
Раздел «План качества» определяет мероприятия по валидации, ответственных и порядок осуществления действий.
3.4.1. Подраздел «Требования заказчика по качеству»
Требования заказчика по качеству являются приоритетными по отношению к Системе управления качеством поставщика (Quality Management System).
Все требования заказчика по качеству перечисляются в данном подразделе, если они отличаются от GAMP. Эти требования должны иметь перекрестные ссылки с соответствующими разделами Pharmaceutical Industry GAMP Supplier Guide.
3.4.2. Подраздел «Система качества поставщика»
В данном подразделе перечисляются все различия между действующей системой качества поставщика и Pharmaceutical Industry GAMP Supplier Guide.
3.5. Раздел «План проекта»
План проекта создается для каждого проекта поставщика.