Я в своей практике часто сталкиваюсь (в т.ч. читая семинар, ссылку на который дал выше), что ключевая проблема - это разговор на разных языка специалистов ИТ и специалистов по управлению качеством /валидации в фарма.

Согласен на 100 процентов - очень сложно донести до ИТ-специалистов, что от них требуется. При этом проблема не сколько в том, что они не хотят, а в том, что действительно разный понятийный аппарат и тебя просто не понимают.

Есть предложение эти пробелы начать потихоньку устранять. Для этого, конечно, нужны специалисты и энтузиасты. На первых порах, ИМХО, вряд ли удастся этот труд монетизировать, но, думаю, со временем это вернётся сторицей, т.к. компьютеризированные системы в фарма будут использоваться со временем только больше и больше. Вместе с тем, я пока лично не встретил ни одного инспектора - будь то украинская Держлiкiнспекцiя, белорусский Центр экспертиз или российский МинПромТорг - кто понимал бы, что скрывается за определением квалификация ИТ-инфраструктуры.

В то же время для ИТ специалиста вовсе не загадка - L3-cхема ЛВС или отслеживание состояния узлов ЛВС посредством NMS.

Я постараюсь эти вопросы в который раз поднять на ближайшей неделе валидации в Москве, направление нужно прорабатывать с привлечением экспертов. Но, думаю, основную ставку сделать на посетителей данного форума.

Уже есть группа энтузиастов, которые могут поучаствовать как в роли соразработчиков проекта, так и оказать финансовую поддержку. Мне кажется, что на базе всевозможных семинаров можно скомпоновать некий дайджест или цикл программных статей, чтобы совместно понять и проработать предмет ВКС.

Я, помимо всего прочего, широко опираюсь на то, что QA IT очень хорошо развито - хорошо определено взаимодействие автора спецификации ПО, кодера, тестировщика, разработаны подходы по тестированию, тестовые стратегии, виды тестирования (функциональное, интеграционное, регрессионное и т.п.), инструментарий типа BTS (Bug Tracking System).

Для многих в фарм отрасли по прежнему загадка, что ВКС после ввода системы в продуктив уже по большом счёту является запоздалой - уже всё разработано и "допиливать" систему в продуктиве, а не в тестовом VLAN'e например, крайне колхозный путь. ВКС ультимативно нужно делать при разработке, начиная с URS - только тогда это формирует добавочную стоимость и позволяет сделать действительно полезный продукт, благодаря которому бегает информация, а не сотрудники с бумажками.

Если Вам, efsol, это интересно, то можете поучаствовать в таком отраслевом проекте - мы о нем много говорим, в т.ч. с завсегдатаями этого форума, но всё никак не можем начать реализовывать. Вместе с тем по моим оценкам время переходить к конкретике пришло. Вдвойне интересно то, что это комп. системы, т.е. независимо от Вашей локализации в проекте можно участвовать дистанционно без особого ущерба в его эффективности.

Вышло довольно сумбурно, но, думаю, основной посыл моего поста понятен.

Да, описание должно быть актуальным и полным. В данном контексте не совсем пойму вопрос, что значит "общим" или "схожим"? Средствами, например, WinCC Flexible создано ПО визуализации для системы...

Доброго дня, Messer!

В моей практике имеются случаи предоставления мануала на серию моделей оборудования (конкретно в данном случае - линии асептического наполнения во флаконы). То есть, между строк понимается "используйте то, что применимо к вашей модификации". Иными словами, у них один файл на несколько разных модификаций оборудования.

Александр Белинский писал(а):

Какое "схожее" при этом описание может быть - для визуализации систем приготовления растворов? ;)

Однако)))) Хороший вопрос! Опять же могли бы подсунуть все что угодно. Мы, специалисты по валидации, не совсем понимаем что может быть написано в Soft Design Specification. А потому, там может быть описано все, что угодно!

Вот нам 3 месяца назад поставили оборудование для приготовления растворов. Спецификация на софт не соответствовала действительности, плюс они сами увидели свой косяк в программе при проведении трех подряд процедур по стерилизации реакторов (оборудование куплено вместе с IQ, OQ). Мануал так же был от какой-то похожей, но не нашей модели. Представитель сказал, что это их стандартная практика - править SDS по месту у заказчика, а потом из своего офиса высылать мануал, соответствующий SDS. Так что, когда-нибудь мы дождемся от изготовителя нового мануала (да, и вообще, всего комплекта документации).

Если бы представитель изготовителя закрыл глаза на "несоответствие в бумажке" (с точки зрения инженеров, это несущественно), то известно каким был бы у нас мануал - что-то среднее между нашей моделью и какой-то еще.