Уведомления
Очистить все

Валидация 1С

35 Сообщения
15 Участники
2 Likes
1,280 Просмотры
0
Автор темы

Добрый день, уважаемые форумчане.
Подскажите, пожалуйста, нужно ли проводить валидацию 1С: Предприятие и 1С: Документооборота?

0
Автор темы

@generationP писал(а):

СОПы, технологические инструкции, инструкции по упаковке, реестры поставщиков, методики, графики, протоколы/отчеты по валидации и другие документы ФСК.

Действительно, планируется перевести всю эту документацию в электронный вид. Спасибо за ответ.
Но с чего тогда начать? URS и FS я написал, правда, не знаю на сколько правильно, IT не сильно помогают, они говорят, что и так тестируют программу. И главный вопрос, как делать все остальное? Где можно хоть что-то прочитать, подсмотреть?

0

Уважаемые коллеги,

валидация EDMS (системы электронного документооборота) - это классический пример при валидации компьютеризированных систем в фарме. Конечно объём этой валидации не безусловный, необходимо выделить GxP-принадлежные функции и/или модули.
Выше коллеги высказались в отношении того, мол, не нужно валидировать MS Office. Владелец форума в своё время привёл перевод документа EDQM где собственно приводились примеры валидации MS Excel и MS Access. Так что тут тоже лучше обойтись без категоричных суждений. Конечно, не нужно "валидировать" меню "файл" или "правка", но если вы делаете уникальные расчёты то валидировать нужно (например, расчёты однородности дозирования, выходы за пределы спецификаций - OOS и т.п.).

Вот об этом же вопросе, но немного шире:

URS и FS я написал, правда, не знаю на сколько правильно, IT не сильно помогают, они говорят, что и так тестируют программу. И главный вопрос, как делать все остальное? Где можно хоть что-то прочитать, подсмотреть?

Это уже правильное начало. Без URS делать в принципе ничего - см. п. 16.6 руководства PIC/S на эту тему. По сути Вам нужно выделить GxP-принадлежные бизнес-процессы в Вашей системе и сосредоточиться на их тестировании.
Говоря упрощённо, если у Вас есть жизненный цикл согласования и утверждения, к примеру, технологической инструкции/протокола производства, то вы должны убедиться, что он функционирует согласно описанию в URS и FS.

То, что IT Вам не помогают - это знакомая история. Спросите Ваше IT знакомы ли они со стандартом IEEE829, который касается как раз QA в IT? Если они "сами тестируют", то не могли бы они предъявить Вам тестовую стратегию, тест-кейсы, баг-трэкинг систему и т.п.?
Подозреваю, что ничего подобного не будет. Но. Тем не менее, начинать этот диалог нужно и начинать делать эту работу точно так же нужно. Приложение 11 GMP никто не отменял, более того, оно будет набирать чем далее, тем бОльший вес. Никого ведь в повседневной жизни не смущают системы интернет-банкинга или телекоммуникационные сервисы? А они ведь точно так же тестируются. В валидации компьютеризированных систем подходы в целом те же, требования практически те же. Для начала запросите Ваше IT-подразделение пусть подготовят логическую схему сети. 1С ведь имеет клиент-серверную архитектуру? Пусть изобразят, используя шаблоны в MS Visio. Это Вам пригодится для квалификации IT-инфраструктуры. Ещё лучше, если IT-подразделения используют какие-либо средства автоматизации управления сервисами/сетью - Nagios, Zabbix и т.п. При квалификации IT-инфраструктуры оттуда можно напечатать отчеты о состоянии сервисов (имеющих отношение к рассматриваемой системе). Если ничего этого нет, значит настало время упорядочивания IT на предприятии. Для этого существуют стандарты ITSM. Иначе по мере усложнения сервисов будет меньше работы, больше "подставка табуреток" под сервисы или сервисы функционировать "под водой". Например, когда по факту на складах используют ту же 1С, а для инспекторов - дублируют информацию в бумажных журналах. При этом больше обманывают сами себя, т.к. двойная бухгалтерия чревата ошибками и непроизводительными потерями времени. Но это отдельная тема.

По Вашей теме - задавайте конкретные вопросы. Попробую помочь.

P.S.: так же была оговорка, мол, "фильтры не валидируются предприятиями". Граждане, ну давайте совсем не впадать в дилетантизм - ISO 14644 для кого написано? 🙂 Тест целостности и герметичности монтажа для кого разработан?

0

Да, ошибся. Да , в данный момент дилетант и лучше бы промолчал. Не всё и сразу 😉

0

В данном случае я бы предложил вернуться к исходному вопросу 🙂

То, что мы не встретим ни в одном руководстве по валидации компьютеризированных систем, однако, что проистекает прямо из логики QA в IT - забываем про инспекторов и регуляторов и вспоминаем прежде всего о собственной выгоде. Написание тест-кейсов и тестирование системы целесообразно тогда и только тогда, когда ведётся её активная разработка. В момент, когда мы имеем дело с уже функционирующим продуктом в продуктивной среде, то, как правило, поздно пить Боржоми - особенно если нет SLA c разработчиком или возможности внести требуемые изменения собственными силами. В таком случае нужно подтвердить основные бизнес-процессы, затрагивая только фронт-энд системы (до бэк-энда, т.е. логики в такой фазе жизненного цикла бывает дотянуться затруднительно). Этот подход для т.н. Legacy System описан в руководстве PIC/S (п. 16.6), на которое я ссылался ранее.

А вот если мы только на этапе создания новой системы, то по классике жанра эта схема работает в QA IT следующим образом. Есть автор спецификации на программный продукт. Как только спецификация готова, этот автор организовывает встречу с кодером и тестировщиком одновременно - они занимаются "хоровым чтением" этой спецификации, совместно выясняют, правильно ли они поняли автора. После этого кодер идёт писать код, а тестировщик - тест-кейсы. Это в идеале. В реале бывают вариации вплоть до полного игнора указанной элементарной схемы. 🙂 Тем больше шансов на выходе получить "колхозное решение".

В конце 2015 для меня было не малым удивлением, что 1С уже подтянулся к методологии ITIL :). Рафинированной выжимкой ITIL являются стандарты ITSM - я упоминал о них ранее - см. ISO 20k. Фаза эксплуатации в Приложении 11 GMP, ИМХО, процентов на 80 % коррелирует с ITSM. Т.е. если мы идём русле практик ITSM - мы автоматически выполняем требования фазы эксплуатации Приложения 11 GMP. Для выполнения требований фазы валидации Приложения 11 GMP достаточно в наиболее общем плане соответствовать подходам, изложенным в IEEE829. GAMP5 всем хорош, но, по большому счёту, это адаптированный для фарма текст по IT-подходам - там красивые диаграммы и таблицы для анализа рисков, прекрасные блок-схемы для управления IT-процессами (существующими и исчерпывающе описанными в ITIL, ITSM), но собственно о том, как тестировать в GAMP5 сказано очень поверхностно, в смысле очень много воды и мало конкретных примеров. Может кто сумел выжать максимум из раздела D, но лично я шаблоны тест-кейсов брал из литературы по QA IT. Примеры с интернет-магазинами и банковскими сервисами куда ближе к практике тестирования той же 1С, чем "обширное теоретизирование" ISPE. Хотя безусловно полезной является их интерпретация Приложения 11 GMP.

0
Автор темы

Спасибо, за ответ, буду пока переваривать все, но уже представляю, что работа будет трудной и интересной.
И, подскажите, это речь только об 1С: ДО или 1С: Предприятие тоже попадает в категорию - валидировать нужно?

0

@Is_pharm_farm писал(а):

И, подскажите, это речь только об 1С: ДО или 1С: Предприятие тоже попадает в категорию - валидировать нужно?

Вот тут уже я хочу избежать поверхностных суждений. И скажу так, что обычно строю свою работу, как это и советует GAMP5 (вот тут он методологически незаменим!), с исходного анализа рисков. Есть вещи очевидные, например финансовые модули или модули управления канцелярской документацией (исходящие письма, приказы по кадрам и т.п.) не являются GxP-принадлежными. Как провести функциональный анализ рисков подробно описано в том же GAMP5 - даже есть таблицы и градации по FMEA. Точно так же "очевидность" может касаться систем прямого влияния - например, SCADA-система склада или управления/логгирования данных по мониторингу - это GxP-принадлежные системы. Эта информация может в определённом объёме входить в досье серии, поэтому её достоверность критична.

А могут быть функции различных систем (ERP, EDMS) не очевидными - тогда нужно детально расшивать бизнес-процессы в рамках анализа рисков, чтобы понять GxP-принадлежность (релевантность). Упрощенно говоря GxP-принадлежными являются те функции КС, которые оказывают влияние на здоровье пациента, качество продукции и целостность данных в отношении этих категорий.

0

Добрый день. Передо мной сейчас поставили задачу сделать алгоритм Валидации информационных систем на базе 1С. Я в ступоре, потому что не силен с английским, с документацией GAMP 5 тяжело мне разобраться.
Прошу помочь, это единственное место в рунете где обсуждалась валидация ис 1с, все надежды на вас.
Мне хотя бы узнать приблизительный алгоритм, какие данные я должен знать, чтобы его составить, как вообще происходит процесс валидации.

0

Приблизительный алгоритм валидации упрощённым языком:

1. Вам необходима URS (User Requirements Specification, спецификация требований пользователя, в простонародье - ТЗ). В ней должны детально быть описанными все требования к бизнес-процессам и функциям, которые реализует Ваша 1С.

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

3. Для выбранных бизнес-процессов и функций Вы проводите последовательное тестирование на предмет соответствия тому, что написано в исходном ТЗ к системе. Ожидаемый результат сравниваете с действительным.

Каждый вышеописанный шаг = документ/комплект документов.

0

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

Приблизительный алгоритм валидации упрощённым языком:

Ну это если для взрослых.
в Российских реалиях все немного проще.
Как правило стоит задача нарисовать что либо отдаленно похожее на правду.
Это так?
У меня давно есть мысль сделать доклад для Недели валидации или тут пост написать.
Валидация КС
Де юре Де факто Де билло.
Да все руки не доходят. Вот если начнем с вами обсуждать эту тему то глядишь он и напишется.

0

Kirillcheg
Давайте. 🙂 Единственный момент, что если на пост-советском пространстве именно в фарма и именно в направлении валидации КС пока "колхоз", это не означает, что нужно идти на поводу у этого тренда. Например, в сопредельных областях ITSM = IT Service Management, ISMS = Information Systems Security Management в РФ и в Украине неплохой уровень зрелости, COBIT5 ISACA официально на русском языке выпустила - так что есть примеры "не колхоза" в сопредельных с валидацией КС областях - почитайте требования Приложения 11 GMP и, например, содержание стандартов ISO20k и ISO27k. Они перекрываются по своим требованиям (речь о фазе эксплуатации) процентов на 70-80%.

Так вот, тот факт валидация КС не выросла из коротких штанишек, вовсе не означает, что нужно расценивать её как фиговый листок для инспектора. Валидация вполне может и должна формировать added value, если этот инструмент применять: а) на этапе проектирования и разработки КС (когда уже всё сделано "абы как", действительно, такая "валидация" - 5-е колесо в телеге); б) с целью обеспечения того, чтобы "бегала" информация (целостная и безопасным образом), а не сотрудники с бумажками.

В российских и украинских банках прекрасно реализованы ISO27k (как требование, а не рекомендация) и, подозреваю, что и IT-разработка там ведется по IEEE829, а не "методом проб и ошибок". Это первая параллель и первый драйвер. Второй драйвер - постепенно регулятор в фарма тоже научится тому, что нужно подразумевать под требованиями Приложения 11 GMP - это способно поменять статус "Де факто" и "Де билло". 🙂 Что Вы будете делать, если как-нибудь первый раз (а к этому всё идёт) по требованиям Приложения 11 вопросы будет задавать приглашённый МинПромТоргом (RU) или Держлiкiнспекцiєю (UA) или Центром Экспертиз (BY) IT-эксперт, а не микробиолог? Третий драйвер - у меня есть опыт общения с некоторыми российскими компаниям, где контракторы из США или ЕС - так вот их представители мне буквально озвучивали следующий тезис, мол, им не интересно, какие вопросы им будет задавать МинПромТорг (они ещё лет пять могут этим не интересоваться). Им важно, чтобы они соответствовали требованиям контракторов - и приводились замечания аудиторов из ФРГ и США. Как Вы понимаете, их фиговый листок не устраивает 🙂 Одно из замечаний касалось того, что была изменена системная дата и распечатан "отчет задним числом" - Вы представляете, чтобы кто-то из наших инспекторов сел бы за Ваше рабочее место, "пошуршал" бы в ОС и выявил бы через лог такой баг? Вместе с тем, когда такой момент наступит, окажется что количество "нарисованных" сервисов будет способным "потопить" регулируемое предприятие.

Страница 2 / 4
Поделиться: