Валидация 1С

Обратная сторона известности 😳 в том, что гадости про родное предприятие не хочется писать 😀
Напомню только вам и поясню другим читателям, что вы работаете на себя а не в колхозе.
Поэтому, настаиваю на том, что колхозникам колхозово а спецам спецово.
Это не значит, что нарисовать фиговый листок для минпромторга раз плюнуть. Здесь как раз нужен опыт и профессионализм (своеобразный). Пост писать все-таки придется.
Ведь "Всюду жизнь" (с).
Все вышесказанное ответа не требует. Если автор вопроса anton alexeev будет задавать вопросы, то буду отвечать по существу.

зы. сейчас как раз дорисовываю валидацию 1С для минпромторга.

Kirillcheg, что касаемо документации, кроме спецификации и функционала, протокола и отчета, какие еще должны быть документы( и с каким содержимым) подготовлены в течении валидации?
Назовите пожалуйста полный пакет документов, который получается за всю процедуру.

И еще. Вашими словами, зачем делать валидацию 1С, какие позитивные эффекты она дает?

Если вы из России и попадаете под действие 916 приказа, то прочтите в нем все, что касается КС. Воспользуйтесь поиском.
Итого получится 4 документа.
1. Спецификация.
2. Протокол квалификации (DQ/IQ/OQ/PQ) - считаем это одним документом.
3. Инструкция по эксплуатации.
4. Инструкция по обслуживанию.

Валидация 1С нужна либо для того что бы показать этот документ аудитору, либо (в нашем случае) устранить замечание выявленное аудитором. Другой пользы от этого, особенно если система уже эксплуатируется 12 лет, нет.

@Kirillcheg писал(а):

Другой пользы от этого, особенно если система уже эксплуатируется 12 лет, нет.

Большей частью согласен - основная ценность валидации КС - при разработке.

Однако, даже ретроспективно эта деятельность не столь бесполезна, как может показаться на первый взгляд (нежелание или неумение извлечь из этого выгоды ещё не означает, что это невозможно, скорее означает, что бюджет на содержание "захламленных сервисов" не ограничен :)) Это моё личное мнение и убеждение. Вот на чём оно основано:

1. Разбираясь с системой ретроспективно Вы имеете возможность навести порядок с учётными записями.
2. Аналогично, разберётесь с разграничением прав пользователей
3. Пройдёте по логической схеме системы (набросанной хотя бы в Visio), в результате, возможно сумеете держать руку на пульсе у Вашего сервиса (при помощи автоматизированных систем состояния сети типа Nagios, Zabbix etc. - вряд ли админы обслуживают Вашу систему "пешком", а если они так делают то их, по идее, должны постоянно бомбить по телефону, мол, почему не проходит проводка такая-то, не можем выписать накладную, не обновлены списки контрагентов и т.п.).

Отговорка мол, условный "Петя-админ" или "Марья Ивановна из бухгалтерии" итак всё знают, зачем это описывать разбивается о простой аргумент - они могут сменить работу и тогда предприятие остается с "захламленным сервисом" с фрагментарными описаниями 12-летней давности (утратившими свою актуальность априори), которую проще снести, чем привести в порядок :). Лично сталкивался с подобными ситуациями.

@Kirillcheg писал(а):

Если вы из России и попадаете под действие 916 приказа, то прочтите в нем все, что касается КС.

Тут не важно, из РФ или нет. И в 916-м Приказе (RU), и в 42-й Настанове (UA), и в ТКП-030 (BY) и в сGMP EU Приложение 11 имеется идентичный текст, менявшийся последний раз в 2011-м.

Добавлю ещё один документ, с которого всё начинается - URS (п. 4.4. Приложения 11).

Добрый день, всем.
Правильный ли подход/план к валидации Legacy System.
1. Валидацию EDMS, в частности 1С: ДО, правильно начинать только после квалификации ИТ-инфраструктуры? Или можно выполнять эти работы совместно?
2. В чем заключается квалификация ИТ-инфраструктуры:
2.1. Подготовка карты сети или логической схемы сети (это одно и тоже?).
2.2. Узнать у ОИТ (отдел информационных технологий) проведена ли виртуализация сети:
2.2.1. Если ДА – то чем?
2.2.2. Если НЕТ - провести.
2.3. Узнать, что используется для резервного копирования данных, как и чем.
2.4. Узнать используют ли ОИТ средства автоматизации управлением сервисами/сетью, откуда можно напечатать отчеты о состоянии этих сервисов/сети. Вопрос – если не используют, то необходимо ли внедрять?
2.5. Куда эти данные прикрепить, т.е. нужно ли разработать протоколы-отчеты отдельно для квалификации ИТ-инфраструктуры:
2.5.1. Если ДА – то какие из этих пунктов куда будут относиться (IQ, OQ, PQ)?
2.5.2. Если НЕТ – то сделать эти документы приложениями к протоколам валидации 1С: ДО?
2.6. Нужно ли что-то еще для квалификации ИН-инфраструктуры? Если, да, то что?
3. По валидации 1С: ДО:
3.1. Ознакомить ОИТ с Приложением 11 Настановы!
3.2. Узнать у ОИТ – есть ли у них на систему ТЗ, составленное ранее, описание системы, история изменений системы, СОПы по эксплуатации, обслуживанию, архивации и резервному копированию:
3.2.1. Если ДА – то запросить и использовать
3.2.2. Если НЕТ – писать совместно.
3.3. Создание URS – описать все функции, которые должна выполнять или уже выполняет система.
3.4. Из URS выделить GxP принадлежные функции.
3.5. Провести анализ рисков этих функций
3.6. Узнать у ОИТ – есть ли результаты тестов этих функций, если проводились ранее.
3.6.1. Если ДА – то использовать
3.6.2. Если НЕТ – то тестировать
3.7. Заполнение протоколов-отчетов по валидации 1С: ДО и квалификации ИТ-инфраструктуры

Is_pharm_farm
вопросов масса, вряд ли за один раз смогу ответить. По порядку.
1. В принципе по классике жанра сначала квалификация ИТ-инфраструктуры, потом - валидация использования ПО. Но это не очень жестко, примерно, как IQ, OQ & PQ - по идее нужно выполнять по порядку, но возможны исключения/варианты, когда часть документальных тестов выполняется после или одновременно с некоторыми практическими испытаниями.
2. Нужно понимать "где живёт" Ваша система и что нужно для её работы.
2.1. Достаточно создать логическую схему (L3 - cхема сеансового уровня модели OSI - вот короткая статья на эту тему). Есть и специализированное ПО, можно и просто в MS Visio нарисовать.
2.2. Виртуализация сети не является обязательной - это по сути прерогатива Вашего ИТ-подразделения для обеспечения требуемого уровня услуг в соотношении с затратами. Вот пару обзоров на тему виртуализации: раз, два. Специально использую простые, живые описания. Более того, если постараться привлечь ИТ-специалистов на Вашу сторону (то ли организационно, то ли в доверительном ключе - Вам по ситуации виднее), то Ваша совместная работа станет обоюдовыгодной. С учётом вышеизложенного на последнем объекте инженер-программист сам сформулировал, что при очередной реструктуризации локальной вычислительной сети (ЛВС, LAN) лучше сразу же в NMS прописывать типы узлов (хостов), чтобы понимать, что "лежит"не абстрактный узел 192.168.1.77, а сервер системы мониторинга микроклимата складских помещений, что существует не выделенная подсетка 192.168.1.0/24 на 254 узла, а именно "производство" или "бухгалтерия".
2.2.1 - самые распространённые варианты - VMWare, Hyper V
2.2.2 - см. выше - если сеть достаточно простая и нагрузки небольшие, нет существенных требований по безопасности/производительности - можно и не делать виртуализацию. Плюсы и минусы этого действа изложены в обзоре по ссылке выше.
2.3. Да, кроме того, нужно периодически и тестировать резервные копии на предмет их работоспособности - это прямое требование п. 7.2. Приложения 11.
2.4. Обычно современные предприятия и фирмы (не только в фарма), где клиентских ПК от нескольких десятков и более имеют системы NMS (Network Monitoring System) - Nagios, Zabbix, Dude etc. Админы - граждане весьма ленивые и им весьма проблематично поддерживать сервисы "пешком". Но опять-таки, прямым требованием это, как ни парадоксально, с точки зрения фармы не является.
2.5 - самый тяжелый вопрос 🙂 никто Вас не ограничивает. Я практикую, исходя из вышеизложенного, оформление отдельного отчета о квалификации всей ИТ-инфраструктуры предприятия - ведь все системы базово используют одну и ту же ИТ-инфраструктуру - лучше её конфигурацию централизовано зафиксировать и отслеживать её состояние и изменения. Вот вопрос, если Вы поменяли Core Switch - Вам нужно в рамках каждой системы это изменение оценивать? Как по мне, это избыточно - актуализировать L3 - cхему, убедиться, что ключевые свойства сети не изменились и всё.
2.5.1. и 2.5.2. Я пришёл к тому, что вообще не привязываюсь к IQ, OQ, PQ (хотя встречал разные подходы и в целом согласен, что квалификация ИТ-инфраструктуры может быть поставлена в соответствие IQ, тесты в "пеcочнице" - OQ, в продуктиве - PQ) - но посокльку практика тестирования КС очень сильно заимствована собственно с QA IT, я использую именно ат-тишную терминологию: тест-кейсы или тестовые сценарии, функциональное тестирование, интеграционное тестирование, регрессионное тестирование и т.п.
2.6. Если есть NMS - лучше распечатать отчеты о состоянии сервисов/узлов сети - обычно используются "светофоры", cигнализирующие о том, что сервис "UP" или "DOWN" ("WARNING") - чаще это говорит о доступности ресурса, достаточности выделенной памяти и т.п. Так Вы поймете не только, где "живёт" Ваш сервис, но и как он себя "чувствует". Тот факт, что к примеру EDMS или LIMS развёрнуты на том или ином сервере ещё не говорит о том, что они работоспособны. Возможно повторюсь, квалификация ИТ-инфраструктуры - это не есть обход завхозом и перепись инвентарных номеров системников и розеток 🙂 Хотя и для этого есть свои программные продукты (IT assets inventory - например от Manage Engine).

Если свести квалификацию ИТ-инфраструктуры к одному тезису, я бы сформулировал его так - нужна вся та информация, которая позволит в случае "полного завала" системы восстановить её с нуля в "чистом поле" с идентичной конфигурацией. Часто сталкиваюсь с репликами ай-тишников, мол, это вам "фарма QA" не понятно, что и как устроено, а профи-сетевик без труда сам разберётся - зачем все эти сложности? 🙂 Контраргумент таков - профи-сетевик (пришедший внезапно на смену текущему, что часто случается) должен сам иметь возможность во всём разобраться без единого звонка предшественнику, что возможно только при формальном документировании.

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

Возвращаясь к ИТ, укажу, что сам GAMP5 в своём "компаньонском томике" от 2010-го сам активно переписывает процессы ITSM/ITIL и даже упоминает COBIT 4 (хотя на самом деле уже есть COBIT5 и он даже официально переведен на русский язык ISACA - но это уже чрезмерная абстракция - я его изучал, но даже в среде ай-тишников это считает слишком "оторванным от жизни" - там неплохо описаны процессы, есть хорошие метрики, но чрезмерно я бы им не увлекался). Так что через раз адресуясь к ИТ-практикам я всего лишь повторяю изложенное в GAMP 5.

Продолжение следует...

Продолжу, постараюсь лаконично

3.1. на Ваше усмотрение - если ваши ай-тишники знакомы, что такое ITSM/ISMS (ISO 20k/ISO 27k) - они заведомо и легко выполнят все требования и Приложения 11
3.2. В пределе как URS можно считать предмет Договора/Приложение к Договору на внедрение 1С:ДО. Там ведь описан объем внедрения на основании которого Ваша компания подписала акт выполненных работ внедренцу? Точно так же, если внедренец выполнял формальное приемочное тестирование - попросите его по максимуму поделиться его результатами, если он их формализовал хоть как-то. Вообще постарайтесь побольше работы отдать именно разработчику/внедренцу/поставщику - это не от лени - вся соль в том,что работы по внедрению и тестированию нужно максимально выполнить на этапе этого самого внедрения и при непосредственном участии внедренца/поставщика/разработчика. Без него и когда система уже давно используется - пройдитесь только по главным сценариям/блок-схемам. Ключевой вопрос - у Вас Договор на поддержку и сопровождение имеется? Если что-то не будет работать, у Вас есть обратная связь, чтобы в систему внести изменения?
3.3 - 3.7 Вроде бы как все очевидно. 3.6.1 Кто для вас конфигурировал 1С - ваши штатные ай-тишники или внешняя контора? Если последнее, то у них могут быть зафиксированы приемочные испытания.

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

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