Вот представьте себе ситуацию – пришлось вам как-то проводить валидацию.
Вы подготовили для этого валидационный план, выполнили все его пункты, квалифицировали все необходимое оборудование, разработали, проверили и ввели в эксплуатацию средства контроля вашего процесса. Выполнили IQ, OQ и PQ. Утвердили все чертежи и процедуры. Провели обучение и все хорошо задокументировали. Ваш итоговый отчет гордо свидетельствует о том, что все запланированные работы были выполнены успешно, а все исключения были подобающим образом разрешены.
Отлично! Справились! Можно спокойно выдохнуть.
Но через некоторое время, может быть через несколько лет, приходит к вам аудитор и начинает задавать по этой валидации вопросы. И вот тут начинается тихий ужас!
Я более чем уверен, что к этому моменту большинство членов исходной команды уже продвинулись по службе и работают на других должностях. Руководители многих групп, которые утверждали протоколы и отчеты, имеют другие обязанности. Но! Документация то не должна зависеть от этого, она должна существовать сама по себе.
Возможно, в этих документах еще будут существовать некоторые перекрестные ссылки (как правило на страницах истории изменений), однако со временем ими становится тяжело пользоваться, особенно, если вы не являетесь одним из специалистов по контролю за документами. Поэтому, когда от аудитора посыпятся наводящие вопросы, то вам неплохо было бы иметь под рукой какой-то инструмент для быстрого нахождения правильных и полных ответов? Этот инструмент не заменит вашу техническую документацию, однако он мог бы объединить в себе все процессы, начиная от разработки процесса, спецификаций, испытаний и т.д., и который согласовывался бы с валидационным отчетом.
Это та область, где я вижу реальную возможность для улучшения большинства систем валидации процессов. Для этого стоит просто воспользоваться наработками группы по валидации компьютеризированных систем (ВКС) и включить в свою документацию матрицу прослеживаемости.
В матрице прослеживаемости, в основном требуемой для ВКС, четко указаны взаимосвязи между требованиями пользователя, спецификациями разработки, тестами и процедурами. Матрица прослеживаемости позволяет создать перелинковку соответствующих спецификаций с тестами (испытаниями), которые должны быть подготовлены и выполнены. С помощью этой матрицы можно проследить каждое требование начиная от проектирования, реализации в виде кода и заканчивая оценкой во время тестирования. Прослеживаемость обеспечивает соблюдение требований и позволяет отследить соответствующие элементы конфигурации/проекта. А то, что все требования верифицированы и могут быть отслежены вплоть до тестов или работ по верификации, показывает, что требование было выполнено.
Эта концепция может быть легко адаптирована для представления взаимосвязи между производственными спецификациями, анализом рисков, испытаниями IQ, OQ, PQ и процедурами, установленными для поддержания вашего процесса в валидированном состоянии. Лучше всего по ней будут ориентироваться те люди, которые не слишком знакомы с процессом, для того, чтобы найти всю документацию, связанную с каким-либо конкретным элементом этого процесса.
На практике каждая ячейка в этом общем примере, конечно же, будет заполнена соответствующим идентификационным номером документа. Обязательно укажите и номер редакции документа. Многие документы будут меняться с течением времени, а вы обязательно захотите сослаться на конкретную редакцию, которая была в силе на момент валидации.
Спецификация продукта | План эксперимента | Критический входной параметр | Контролируемые элементы | Испытания, проверки и корректировки | ||||
Спецификация герметичности запайки | Критические входные параметры процесса | Температура | Нагревательный элемент | IQ | PM | |||
Регулятор температуры | IQ/OQ | Калибровка | ||||||
Настройки температуры | DOE | DOE | Таблицы настройки | Операционные процедуры | Обучение |
В принципе, вы можете начать создавать матрицу с самого раннего этапа процесса разработки, но я думаю, что имеет смысл начинать со спецификации вашего готового продукта, показатели которой будут использоваться для производства. После того как вы определитесь с отправной и заключительной точкой, создайте карту из всех показателей спецификации используя для этого план эксперимента (DOE), квалификацию оборудования, нагрузочные испытания и документацию на серию.
Упражняясь в создании данной матрицы вы постепенно стандартизируете её в виде шаблона. В дальнейшем вы сможете использовать эту матрицу в двух разных случаях. В первом случае она послужит в качестве демонстрация того, где и как каждый элемент процесса был разработан, испытан и проконтролирован. Во втором случае её можно будет использовать в качестве средства аудита, чтобы явно продемонстрировать, что каждый элемент был полностью валидирован.
Такая прослеживаемость должна быть в каждом протоколе квалификации, т.е. каждое испытание при квалификации должно быть прослеживаемо (с указанием номера пункта в URS и других документах) к соответствующему требованию в URS или других документах, где оно изложено.
Тогда сделать матрицу не составит никакого труда.
К сожалению, то что я обычно вижу в протоколах квалификации, которые попадаются – это совершенно произвольный набор испытаний, который никак не обоснован. Тогда, конечно, без матрицы никак не обойтись. Но это уже получается некая дополнительная работа по исправлению изначально “неправильного” подхода к квалификации.
На одном из семинаров в ВИАЛЕК я показывал такую таблицу требований, как она выглядит в протоколе.
Олег, большое спасибо за дополнение!
Небольшое уточнение – можно подискутировать на счёт “базовости” требования иметь матрицу прослеживаемости для ВКС – сейчас я в числе согласователей (reviewers) ISPE Baseline Volume 5 Commissioning & Qualification (2nd edition) – там матрица тоже выводится, как полезный документ для любого оборудования или системы, не только для ВКС. Но не обязательный. Тем не менее, я бы сказал, что она полезна ещё на этапе URS и в ряде применений гораздо эффективнее DQ. Именно из-за перекрёстных ссылок и отсутствия “воды”.
Наверное я не совсем удачно сформулировал эту часть, поэтому переписал её в менее строгой тональности. В целом согласен, что она не является строгим базовым требованием.
Всегда составляю и поддерживаю в актуальном состоянии traceability matrix при работе с КС. Очень удобный инструмент, не только для поиска информации при инспекциях, но и при работе с изменениями. Можно легко найти документы, которые могут быть затронуты изменением, внести в них правки и выпустить новые версии. Единственная сложность возникает, когда такая матрица создается ретроспективно, еще и по документам поставщика, особенно если эти самые документы составлены сплошным текстом без четкого разделения на тематические блоки. Подготовка матрицы в таком случае занимает достаточно большое кол-во времени и не всегда оправдана с точки зрения затраченных ресурсов.
Павел, спасибо за дополнение!