Как составить Валидационный мастер план?
Здравствуйте, дамы и господа!
Может быть кто-то знает – как выглядит этот самый Validation Master Plan? Что именно в нем отражать – мне более-менее понятно, а вот как должен выглядеть документ –я не знаю.
Регламентирована ли форма документа?
Существуют ли шаблоны (примеры ) мастер-плана?
Я постараюсь этот вопрос рассмотреть очень детально 13-14 декабря в меру своего представления о предмете и с учётом "встреченных" мною объектов. Как я неоднократно говорил - ключевая особенность, что собственно QA IT развито очень хорошо, а вот почему-то именно в фарма это представляет собой загадку, начиная с самого первого вопроса, что собственно валидировать - какие системы подлежат валидации, какие нет. Далее, в каком объеме валидировать подлежащие валидации системы и т.п. Да ладно валидировать - половина epic fail'ов заключается в абсолютном неумении вперемешку с нежеланием проработать URS. 🙂
Александр Белинский
А будет видео-трансляция или запись семинара? Или все только для участников?
efsol
пока мы трансляции не организовываем. В будущем планировали вэбинары устраивать, но там немного другой формат видится - максимум час-полтора. Впрочем, возможно на данном ресурсе я обновлю блог на эту тему - он-то будет бесплатно доступен - но нужно найти для этого время. Пока могу только размышления на тему от коллеги предложить.
Александр Белинский
Спасибо. С этим материалом я как раз на днях ознакомился
efsol
я посмотрел Ваш профиль - Вы как раз специалист предметной области, поэтому есть предложение всем вместе прорабатывать тему ВКС (валидации компьютеризированных систем, клише с английского термина CSV = Computerised System Validation). До блога руки в ближайшее время категорически не доходят, но важна не форма, а сущность. Сущность состоит в том, что по теме ВКС по моему мнению пока все очень осторожно высказываются в наших постсоветских странах. В ISPE никого из нас брать не собираются в ближайшее время, есть мысль на базе украинского фармацевтического форума сделать по сути русскоязычный аналог GAMP'a. Потому как постановка вопросов современного оригинального GAMP'а малоактуальна для наших условных Витебска, Черкасс или Белгорода. Для наших широт рано обсуждать аспекты Data Integrity - это тематика многочисленных конференций CoP ISPE GAMP во Флориде и Брюсселе. У нас пока боятся MS Excel. Владелец сайта (Антон Мымриков) сделал многое, чтобы эти опасения развеять. Но это только начало пути.
Я в своей практике часто сталкиваюсь (в т.ч. читая семинар, ссылку на который дал выше), что ключевая проблема - это разговор на разных языка специалистов ИТ и специалистов по управлению качеством /валидации в фарма.
Есть предложение эти пробелы начать потихоньку устранять. Для этого, конечно, нужны специалисты и энтузиасты. На первых порах, ИМХО, вряд ли удастся этот труд монетизировать, но, думаю, со временем это вернётся сторицей, т.к. компьютеризированные системы в фарма будут использоваться со временем только больше и больше. Вместе с тем, я пока лично не встретил ни одного инспектора - будь то украинская Держлiкiнспекцiя, белорусский Центр экспертиз или российский МинПромТорг - кто понимал бы, что скрывается за определением квалификация ИТ-инфраструктуры.
В то же время для ИТ специалиста вовсе не загадка - L3-cхема ЛВС или отслеживание состояния узлов ЛВС посредством NMS.
Я постараюсь эти вопросы в который раз поднять на ближайшей неделе валидации в Москве, направление нужно прорабатывать с привлечением экспертов. Но, думаю, основную ставку сделать на посетителей данного форума.
Уже есть группа энтузиастов, которые могут поучаствовать как в роли соразработчиков проекта, так и оказать финансовую поддержку. Мне кажется, что на базе всевозможных семинаров можно скомпоновать некий дайджест или цикл программных статей, чтобы совместно понять и проработать предмет ВКС.
Я, помимо всего прочего, широко опираюсь на то, что QA IT очень хорошо развито - хорошо определено взаимодействие автора спецификации ПО, кодера, тестировщика, разработаны подходы по тестированию, тестовые стратегии, виды тестирования (функциональное, интеграционное, регрессионное и т.п.), инструментарий типа BTS (Bug Tracking System).
Для многих в фарм отрасли по прежнему загадка, что ВКС после ввода системы в продуктив уже по большом счёту является запоздалой - уже всё разработано и "допиливать" систему в продуктиве, а не в тестовом VLAN'e например, крайне колхозный путь. ВКС ультимативно нужно делать при разработке, начиная с URS - только тогда это формирует добавочную стоимость и позволяет сделать действительно полезный продукт, благодаря которому бегает информация, а не сотрудники с бумажками.
Если Вам, efsol, это интересно, то можете поучаствовать в таком отраслевом проекте - мы о нем много говорим, в т.ч. с завсегдатаями этого форума, но всё никак не можем начать реализовывать. Вместе с тем по моим оценкам время переходить к конкретике пришло. Вдвойне интересно то, что это комп. системы, т.е. независимо от Вашей локализации в проекте можно участвовать дистанционно без особого ущерба в его эффективности.
Вышло довольно сумбурно, но, думаю, основной посыл моего поста понятен.
