Юридическое мышление

Автор: Попов Алексей

Дата публикации: 22.04.2022 (статья из архива 23.12.2019)

Мы постоянно работаем с техническими требованиями. Требованиями регуляторных органов, требованиями из стандартов, руководств и т.п. Какие требования выбирать? Как выбрать требование и не получить потом по шапке от кого-либо из бесконечных регуляторов? То что я вам сегодня расскажу, есть ничто иное как правильный и оптимальный подход к анализу требований. Он является алгоритмом правильного отбора и отсечения требований так, чтобы по итогу всем было счастье. Данный подход является на первый взгляд очевидным, но мои личные наблюдения показывают, что специалисты любят нарушить эту последовательность от чего потом сами же и страдают (или их предприятия).

Итак, поехали.

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

Жизненная ситуация, в которой применим данный подход, до слез знакома каждому специалисту в области качества и выглядит следующим образом: мы определили, что некий объект не управляется, хотя должен. Разбиваем этот объект на набор параметров / частей / свойств и здесь у нас возникает тот самый вопрос: Как этим всем управлять? Какой минимум требований нужно выполнить? Конечно можно всегда выбрать все, выбрать самые жесткие, но точно нужно ли?.. 

Типичные вопросы из данной серии:

— как сделать, чтобы к датчику на производстве не было проблем с точки зрения законодательства?

— как и с какой периодичностью проводить мониторинг счетного количества частиц в чистых помещениях?

— как ввести в эксплуатацию этот прибор?

— что обязательно должно быть в URS на это оборудование?

— сколько делать повторов?

— как писать этот документ?

— как проводить эту процедуру? и т.д.

Непосредственно сама блок-схема:

1 Поиск требований

Это самая важная часть, т.к. от нее зависит то, насколько корректное решение вы примете по итогу. На данной стадии необходимо по возможности найти все доступные варианты решения возникшего вопроса. 

По итогу в зависимости от глобальности вопроса вы должны проанализировать и собрать (хотя бы у себя в голове) перечень технических требований в следующих источниках:

акты законодательства вашей страны (законы, постановления, приказы, правила, инструкции и т.д.);

государственные и союзные стандарты (ГОСТ, СТБ, ДСТУ, ГОСТ Р, РМГ);

документы из сферы регулирования вашей страны и вашего союза (СанПиНы, ГН, пожарные нормы и правила, ПМГ, строительные нормы, технические регламенты, типовые правила охраны труда и т.д.)

ЛНПА вашего предприятия (положения о подразделениях, должностные инструкции, инструкции по охране труда, положения о премировании, штатное расписание и т.д.);

имеющиеся процедуры и негласные правила вашего предприятия (существующие политики, СОПы, СТП / СТО, нормы труда, kpi, нормы расхода материалов, валидационные протоколы и отчеты, технологические инструкции / регламенты);

национальные документы других стран и союзов (CFR, PDA, Руководства от FDA, GMP EU, USP, EP, Pic/S, ICH, EN и т.д.);

документы, стандарты и руководства международных организаций, организаций специалистов (ISPE, IEC, ISO, IEEE, OIML, WHO и т.д.);

договорные требования с вашими заказчиками;

требования из авторитетной литературы;

данные из научных исследований;

техническая документация производителя, разработчика, поставщика;

другое, про что я не вспомнил при составлении этого списка.

Итак, у нас есть перечень требований, разной степени детализации, разных численных значений или разной степени применимости. Но они есть и мы идем дальше.

2 Грубая фильтрация

Данная стадия до безобразия проста на первый вид, но является при этом также очень ответственной. На данной стадии мы должны разделить четко все требования на:

— точно обязательные для нас;

— и точно НЕ обязательные для нас.

Третьего не дано. Все разночтения должны решиться на этом этапе.

Обязательными для вас являются следующие требования:

— все применимые НПА вашей страны (законы, приказы, инструкции, постановления гос органов);

— все документы, на соответствие которым вы заявили (сертифицировались, аккредитовались, указали на маркировке, в НД на продукцию и т.д.) (GMP, НД на готовую продукцию, ISO/IEC 17025, стандарты на сертифицированные системы менеджмента);

— все применимые НПА и документы той страны (сообщества), на соответствие которым вы заявили (сертифицировались, получили документ соответствия и т.д.) (GMP EU, CFR, документы FDA, документы Pic/S и т.д.);

— ратифицированные (введенные в действие правительством) требования наднациональных актов (союзов) и соглашений вашей страны (ПМГ, Решения и Правила принятые в рамках ЕАЭС);

— требования ваших заказчиков;

— ваши внутренние ЛНПА;

— ваши внутренние процедуры, которые уже введены.

Также необходимо помнить, что стандарты (или их часть) также могут быть обязательны в ряде случаев, например, если в законодательстве приведены ссылки на эти документы. Также документ (или его часть) из добровольного переходит в обязательный, если в обязательном стандарте есть ссылка на него. При этом отличить является весь стандарт обязательным или его часть можно из контекста: если говорится, что что-то необходимо выполнить в соответствии с положениями какого-то стандарта, а это “что-то” приведено только в двух абзацах, то тогда только эти два абзаца и обязательны. Обратная ситуация, когда дается ссылка, например, на ГОСТ, который является МВИ (нужно при помощи него проводить измерения), то очевидно, что он становится обязательным ВЕСЬ.

Также нужно внимательно смотреть на формулировки требований. В русскоязычных документах, как правило, все обязательные требования приводятся со словами “требуется”, “необходимо”, “следует”, “должно”, “нужно”, “запрещено”, “нельзя”. Но в то же время необходимо помнить, что в английском тексте стандартов ISO и ряде других стандартов профессиональных организаций по стандартизации, перед текстом приводится приписка, что такие то слова выражают ту либо иную степень обязательности. Соответственно, например, стандарты ISO, принятые у нас в виде идентичного перевода, содержат аналогичные требования. И в данном пояснении говорится, что обязательными требованиями являются только требования со словом shall (должен), а вот слово should (следует) передает рекомендательных характер требования. Если подытожить, то мы выбираем те требования, которые по формулировке действительно являются обязательными.

 

Так вот, мы выбрали все обязательные требования. И по отношению к ним все очень просто: эти требования ОБЯЗАТЕЛЬНЫ и должны быть выполнены вне зависимости от отсутствия в них логики и смысла. Да. Они могут быть тупы, они могут не учитывать важные аспекты, но здесь мы просто отправляем на выполнение без рассуждения. Рассуждения в данном случае беспредметны, т.к. правильно выбранные требования нельзя отнести к необязательным никакими способами и даже всемогущим анализом рисков.

В то же время, т.к. данные требования должны быть применимы все вместе, то возникают (причем бывает часто, особенно в российском правовом поле) несколько возможных вариантов проблем:

  1. противоречия документов друг другу в одном и том же вопросе (коллизия), т.е. когда несколько документов нормируют одно и тоже, но не могут быть выполнены одновременно;
  2. требования одних пересекаются с другими, но не совпадают полностью (например, один говорит, что температура должна быть 25-30 оС, а другой, что должно быть 27-33 оС);
  3. требования не выполнимы по техническим или логическим причинам.

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

Решение коллизий в документах одной страны решается при помощи правил юридической силы. Смысл их следующий: в случае коллизии мы выбираем требования того акта, который имеет бОльшую юридическую силу. Порядок юридической силы у каждой страны свой, но общий смысл такой:

— наднациональные акты (например, Правила GMP ЕАЭС) и международные соглашения имеют самую высокую юридическую силу;

— Законы;

— постановления и приказы;

— ЛНПА предприятия;

— внутренние процедуры.

Если же у вас коллизия с требованиями заказчика, требованиями обязательными для вас документами, но другой страны, то коллизии переходят в разряд нерешаемых, т.к. инспекции ведомственно никак не связаны. Что в этом случае делать? Либо исключать возникшую проблему отказом от соответствия одной из сторон, разделением объекта нормирования на две части и применение противоречащих требований по отдельности к каждой, выполнение и одной и второй процедуры одновременно. Ну а если никак, то нарушать требования нам не привыкать, особенно, если регуляторы понимают их несовместимость.

 

3 Тонкая фильтрация

Здесь необходимо также сделать некоторое важное уточнение. Бывают требования рекомендательного и добровольного характера. Они оба являются необязательными и оба могут быть с глаголами “можно” и “рекомендуется”, но у них есть принципиальная разница: в случае невыполнения рекомендательного требования, необходимо предложить свой вариант, а добровольное требование является дополнительным / избыточным и может не выполняться без ввода альтернативных требований. Сформулировать понятнее разницу, к сожалению, не могу, т.к. надо смотреть в каждом конкретном случае и это следует из контекста.

Так вот. Мы с горем пополам отнесли требования к обязательным и необязательным. Обязательные отправили безоговорочно на выполнение и теперь думаем над оставшимися. Вот на этом этапе нужно немного забыть, что вы инженеры, QA или кто-то там еще и взглянуть на все это еще и с точки зрения адекватного собственника.

Здесь вы должны найти компромисс между риском для предмета нормирования (риск для безопасности и качества продукции, риск поломки оборудования, риски для долгосрочных экономических потерь и т.д.) и экономическими затратами на контроль этого риска. Это означает, что вы можете поставить контроль и зарегулировать всё, что у вас есть. Вы можете выполнять самые свирепые требования от самых свирепых организаций. Вы можете валидировать компьютеризированные системы по GAMP (не кидайте в меня камни). Вы можете проверять свое оборудование хоть каждый час. Вы можете поставить четыре каскада переодевания для входа в класс D. Вы можете поддерживать относительную влажность на уровне 40 %-60 %. Но точно нужно ли? Сколько вы затратите на этот контроль? Сколько нужно человеко-часов? А на сколько улучшится качество продукции? Ну как?! Всё же, что мы делаем направлено на контроль безопасности и эффективности препаратов. Поэтому задайте вопрос: как отразится введение этого требования на безопасности продукции? А как отразится, если не ввести это требование? Нужно ли оно в таком варианте? А может можно сократить? Уменьшить? Снизить периодичность? Избавиться в принципе?

Не стоит впадать в крайности и выполнять требования самых жестких необязательных документов, т.к. да, вы сможете сказать потом, что у вас на заводе ОГО-ГО, мы там так сделали, у нас там так всё ЖЕСТОЧАЙШЕ, что вот вам и не снилось, но… кому это нужно? Не создавайте себе проблем и своим коллегам по предприятию. На заводах и так всегда на все не хватает времени и что-то не делается, подделывается, скрывается, не упоминается и т.д. Освободив время после скидывания с себя лишних необязательных требования, вы можете приступить к тому, для чего не было времени ранее. 

Если подытожить этот пункт, то вы должны взглянуть на каждое необязательное требование с учетом:

— политики вашего предприятия;

— действующих процедур;

— технической оснащенности;

— наличия на предприятии специалистов с нужной компетентностью;

— экономической целесообразности;

— вашего желания заниматься эти.

При этом добровольные требования можно скидывать просто без каких-либо объяснений, отвечая в случае чего, что они для вас “нецелесообразны”, “избыточны”, “низкие риски” и т.д.

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

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

Подобных вопросов много и они риторические.

4 Окончание процесса

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

Здесь нужно понимать, что обязательные и необязательные требования носят, кроме очевидных своих свойств, также разную философию. Обязательные требования — это требования, решение о необходимости выполнения которых взял на себя регулятор. Это регулятор решил, что вам нужно делать так или иначе. Вы не должны понимать или объяснять почему нужно делать именно так. Так написано. В случае необязательных требований ситуация абсолютно обратная. Даже если это не вами придуманные требования, а эти подходы придумали международные признанные организации, авторитетные авторы или ассоциации, то все равно за решение об их выборе, исполнении, а также за последствия от их внедрения несете вы и только вы. Нельзя будет сказать, что у вас ушла в реализацию бракованная продукция, потому что вы выполняли требования признанной организации XXX. Ответственность только ваша. Вы считаете для себя их методы подходящими — вы их внедряете.

Также следует понимать, что все необязательные требования, которые прописаны в вашей документации, становятся автоматически для вас обязательными. Это называется принцип самообязания или “добровольно заявили о своем соответствии”. После того как у вас в СОПах появились конкретные положения, сказать, что вы сегодня не будете их выполнять, потому что они добровольные, уже нельзя. 

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

Удачного дня.