Ситуация:
Недавно столкнулся с интересным примером из практики. Консультант из ВНИИИМТа в рамках их проекта «одно окно» при внедрении СМК убедил клиента в том, что все запланированные мероприятия должны оформляться как предупреждающие действия, а любые незапланированные изменения — через процедуру корректирующих действий.
Клиент теперь, следуя этой рекомендации, любое изменение в процессах или документации оформляется через соответствующие формы, предусмотренные в его процедуре САРА по п.п. 8.5.2 и 8.5.3 стандарта ISO 13485.
Формально рекомендация была дана в рамках консалтинга, однако в ближайшее время клиент ожидает инспекционный аудит от той же организации — ВНИИИМТ. И, не исключено, что проверку будет проводить тот же специалист или его коллега. В итоге "совет" консультанта воспринимается как обязательное условие: иначе могут быть проблемы…
Оставим в стороне мигающий в этой ситуации аварийным цветом конфликт интересов - обратимся к СМК.
Нарушения требований ISO 13485 здесь нет — оформление предупреждающих и корректирующих действий действительно требуется стандартом. Однако ситуация демонстрирует методологическое смешение понятий и приводит к чрезмерной формализации: даже плановое изменение теперь требует запуска процедуры CAPA.
В нормальной практике корректирующие действия — это реакция на выявленные несоответствия и причины проблем. Предупреждающие действия — это ответ на потенциальные риски. Не каждое изменение в СМК связано с несоответствиями или рисками. Например, обновление инструкции, внедрение нового шаблона документа или плановое улучшение процесса вполне могут быть частью регулярной работы и оформляться в рамках обычного управления изменениями.
Следование букве, а не духу стандарта, превращает СМК в машину по производству бумаг. Сотрудники тратят время на формальные процедуры, которые не добавляют реальной ценности. В результате — больше бюрократии, меньше гибкости и результативности.
Этот случай — хороший повод обсудить важный методологический вопрос: в чём разница между корректирующими/предупреждающими действиями и просто изменениями в СМК? Как не перегрузить систему, не нарушая требований стандарта? Где граница между управлением несоответствиями и обычной деятельностью по улучшению?
Буду рад услышать мнение коллег: как Вы разграничиваете эти понятия у себя на практике?
Недавно столкнулся с интересным примером из практики. Консультант из ВНИИИМТа в рамках их проекта «одно окно» при внедрении СМК убедил клиента в том, что все запланированные мероприятия должны оформляться как предупреждающие действия, а любые незапланированные изменения — через процедуру корректирующих действий.
Клиент теперь, следуя этой рекомендации, любое изменение в процессах или документации оформляется через соответствующие формы, предусмотренные в его процедуре САРА по п.п. 8.5.2 и 8.5.3 стандарта ISO 13485.
Формально рекомендация была дана в рамках консалтинга, однако в ближайшее время клиент ожидает инспекционный аудит от той же организации — ВНИИИМТ. И, не исключено, что проверку будет проводить тот же специалист или его коллега. В итоге "совет" консультанта воспринимается как обязательное условие: иначе могут быть проблемы…
Оставим в стороне мигающий в этой ситуации аварийным цветом конфликт интересов - обратимся к СМК.
Нарушения требований ISO 13485 здесь нет — оформление предупреждающих и корректирующих действий действительно требуется стандартом. Однако ситуация демонстрирует методологическое смешение понятий и приводит к чрезмерной формализации: даже плановое изменение теперь требует запуска процедуры CAPA.
В нормальной практике корректирующие действия — это реакция на выявленные несоответствия и причины проблем. Предупреждающие действия — это ответ на потенциальные риски. Не каждое изменение в СМК связано с несоответствиями или рисками. Например, обновление инструкции, внедрение нового шаблона документа или плановое улучшение процесса вполне могут быть частью регулярной работы и оформляться в рамках обычного управления изменениями.
Следование букве, а не духу стандарта, превращает СМК в машину по производству бумаг. Сотрудники тратят время на формальные процедуры, которые не добавляют реальной ценности. В результате — больше бюрократии, меньше гибкости и результативности.
Этот случай — хороший повод обсудить важный методологический вопрос: в чём разница между корректирующими/предупреждающими действиями и просто изменениями в СМК? Как не перегрузить систему, не нарушая требований стандарта? Где граница между управлением несоответствиями и обычной деятельностью по улучшению?
Буду рад услышать мнение коллег: как Вы разграничиваете эти понятия у себя на практике?
👍10
Почему_не_все_изменения_в_СУК_должны_оформляться_через_CAPA_pdf.docx
163.8 KB
Рассмотрев ситуацию которую я описал выше пришлось подготовить специальный гайд. Используйте, критикуйте, улучшайте!
👍6
Компания производящая медизделия зачем-то навязала себе требования ISO9001 ☹️
Я понимаю когда бизнес делал это 10 лет назад - тогда про специфический стандарт для производителей МИ мало кто слышал и во многих тендерах в качестве критерия наличия СМК упоминалась только девятка. Но теперь-то!
Анализирую документы такой компании..
Вот, классическое несоответствие вызванное противоречием имеющем место в упомянутых выше двух стандартах:
😱 В РК (включая разделы, посвящённые политике качества, планированию, анализу рисков и ответственности руководства) используется термин «риск» без уточнения его смысла. Не проводится разграничение между понятием «риск» как неопределённость, влияющая на результативность процессов СМК (ISO 9001) и «риск, связанный с безопасностью медицинских изделий» (ISO 13485, ISO 14971). Кроме того, во фразах о планировании действий в отношении рисков отсутствует упоминание о возможностях, что является обязательным согласно ISO 9001:2015, п. 6.1.
Я понимаю когда бизнес делал это 10 лет назад - тогда про специфический стандарт для производителей МИ мало кто слышал и во многих тендерах в качестве критерия наличия СМК упоминалась только девятка. Но теперь-то!
Анализирую документы такой компании..
Вот, классическое несоответствие вызванное противоречием имеющем место в упомянутых выше двух стандартах:
😱 В РК (включая разделы, посвящённые политике качества, планированию, анализу рисков и ответственности руководства) используется термин «риск» без уточнения его смысла. Не проводится разграничение между понятием «риск» как неопределённость, влияющая на результативность процессов СМК (ISO 9001) и «риск, связанный с безопасностью медицинских изделий» (ISO 13485, ISO 14971). Кроме того, во фразах о планировании действий в отношении рисков отсутствует упоминание о возможностях, что является обязательным согласно ISO 9001:2015, п. 6.1.
👍7
Коллеги, один и тот же косяк встречается у каждого четвёртого — а может быть и у каждого третьего — в Руководстве по качеству.
Вместо того чтобы кратко и по делу объяснить, как Вы выполняете то или иное требование стандарта, или хотя бы дать ссылку на документ, где это описано, Вы пишете декларации типа «мы выполняем требование X».
То есть берёте норму из стандарта и переписываете её в утвердительном наклонении. Было: "организация должна...", стало: "организация выполняет..."😇
Запишите афоризм от вашего покорного слуги:
👉 Руководство по качеству — это не пересказ стандарта, а ответ на вопрос “Как именно мы это делаем?”
Вместо того чтобы кратко и по делу объяснить, как Вы выполняете то или иное требование стандарта, или хотя бы дать ссылку на документ, где это описано, Вы пишете декларации типа «мы выполняем требование X».
То есть берёте норму из стандарта и переписываете её в утвердительном наклонении. Было: "организация должна...", стало: "организация выполняет..."
Запишите афоризм от вашего покорного слуги:
👉 Руководство по качеству — это не пересказ стандарта, а ответ на вопрос “Как именно мы это делаем?”
Please open Telegram to view this post
VIEW IN TELEGRAM
👍13
Коллеги, ещё одна типовая ошибка при составлении Руководства по качеству — желание прописать всё и сразу.
Причём всё — это по каждому требованию стандарта, по каждой запятой.
Желание, конечно, похвальное 😊 Но если у Вас уже есть отдельная процедура, в которой весь процесс детально описан, с формами, ролями и маршрутами — зачем дублировать всё это в РК?
📌 Пример: раздел 7.3 «Проектирование и разработка». Там аж 10 подпунктов. Но в самом начале — требование: должна быть документированная процедура.
Вот и дайте ссылку на неё! А в РК напишите по-человечески, например так:
- Процесс проектирования и разработки регулируется процедурой СОП 7.3, в которой описан порядок планирования, исполнения и мониторинга.
- Формы записей — обязательные и рекомендуемые — указаны в самой процедуре.
- Проектированием занимается отдел главного конструктора.
- На этапах верификации и валидации подключаются ОТК и регуляторный отдел.
- На стадии технологической подготовки — производственный отдел.
И никаких простыней на 3 страницы 👌
Причём всё — это по каждому требованию стандарта, по каждой запятой.
Желание, конечно, похвальное 😊 Но если у Вас уже есть отдельная процедура, в которой весь процесс детально описан, с формами, ролями и маршрутами — зачем дублировать всё это в РК?
📌 Пример: раздел 7.3 «Проектирование и разработка». Там аж 10 подпунктов. Но в самом начале — требование: должна быть документированная процедура.
Вот и дайте ссылку на неё! А в РК напишите по-человечески, например так:
- Процесс проектирования и разработки регулируется процедурой СОП 7.3, в которой описан порядок планирования, исполнения и мониторинга.
- Формы записей — обязательные и рекомендуемые — указаны в самой процедуре.
- Проектированием занимается отдел главного конструктора.
- На этапах верификации и валидации подключаются ОТК и регуляторный отдел.
- На стадии технологической подготовки — производственный отдел.
И никаких простыней на 3 страницы 👌
👍21
Аргументы_по_удалению_ISO_9001_из_области_действия_системы.docx
16.4 KB
Коллеги, уже не в первый раз сталкиваюсь с производителем медицинского изделия, у которого помимо ISO 13485 ещё и внедрён ISO 9001. И каждый раз задаюсь одним и тем же вопросом: зачем?
Вот реально — что движет Вашим руководством, когда оно решает повесить на себя дополнительные требования, дополнительные проверки, дополнительные риски несоответствий? Какие тут логические или хотя бы экономические мотивы?
Я вот недавно для одного такого предприятия готовил пояснительную записку на тему целесообразности исключения ISO 9001 из области применения СМК — прилагаю ниже. Может, кому пригодится для внутреннего диалога с "убеждёнными сторонниками двух стандартов сразу". 😊
Вот реально — что движет Вашим руководством, когда оно решает повесить на себя дополнительные требования, дополнительные проверки, дополнительные риски несоответствий? Какие тут логические или хотя бы экономические мотивы?
Я вот недавно для одного такого предприятия готовил пояснительную записку на тему целесообразности исключения ISO 9001 из области применения СМК — прилагаю ниже. Может, кому пригодится для внутреннего диалога с "убеждёнными сторонниками двух стандартов сразу". 😊
🔥9
Прошёл Я тут недавно обучение по ГОСТ IEC 62304-2022, Спасибо Михаилу Виноградову 😊 Теперь вот понимаю что в 99 процедурах по управлению записями из 100 которые я у кого-либо встречал есть вот этот вот проблема которую только что я тут одному клиенту описал:
------------
Основные записи СМК в Вашей компании, по сути, — это, на мой взгляд, именно те записи, которые сопровождают разные стадии разработки, внедрения и поддержки ПО. Особенно если речь идёт о медизделиях с ПО — тут без этого никуда.
Чтобы разобраться, какие именно записи критичны, стоит обратить внимание на стандарт ГОСТ IEC 62304-2022. Я вставил ниже несколько ключевых определений из этого стандарта — они, на мой взгляд, имеют максимальное значение именно для управления записями в контексте жизненного цикла ПО. В идеале, в данной процедуре следовало бы раскрыть специфику управления такими записями: как обеспечивается прослеживаемость, какие документы считаются записями, где и как они хранятся, как защищаются от изменений, и как осуществляется доступ к ним.
Сейчас же в процедуре даже Jira (или другой аналогичный инструмент, который наверняка используется при разработке) не упоминается вообще… ☹️ Это делает процедуру довольно «отвязанной» от реальных процессов сопровождения жизненного цикла ПО.
Если компания всерьёз планирует реализовывать IEC 62304, стоит как минимум подумать над включением:
- понятий вроде «артефакт жизненного цикла ПО», «запись о жизненном цикле ПО», «управление конфигурацией ПО», «результаты тестирования ПО»;
- описания, какие записи формируются на каждой стадии разработки (требования, проектирование, верификация, тесты, исправления);
упоминаний об инструментах (таких как Jira, Git, Confluence), через которые ведутся эти записи — даже если на уровне ссылки или примечания;
- того, как эти записи попадают в СМК, кто их регистрирует, кто за них отвечает, и как они проверяются при аудитах.
Без этих дополнений процедура, скорее, относится к "бумажной" СМК, а не к современной инженерной системе управления разработкой программных компонентов медицинских изделий.
------------
Основные записи СМК в Вашей компании, по сути, — это, на мой взгляд, именно те записи, которые сопровождают разные стадии разработки, внедрения и поддержки ПО. Особенно если речь идёт о медизделиях с ПО — тут без этого никуда.
Чтобы разобраться, какие именно записи критичны, стоит обратить внимание на стандарт ГОСТ IEC 62304-2022. Я вставил ниже несколько ключевых определений из этого стандарта — они, на мой взгляд, имеют максимальное значение именно для управления записями в контексте жизненного цикла ПО. В идеале, в данной процедуре следовало бы раскрыть специфику управления такими записями: как обеспечивается прослеживаемость, какие документы считаются записями, где и как они хранятся, как защищаются от изменений, и как осуществляется доступ к ним.
Сейчас же в процедуре даже Jira (или другой аналогичный инструмент, который наверняка используется при разработке) не упоминается вообще… ☹️ Это делает процедуру довольно «отвязанной» от реальных процессов сопровождения жизненного цикла ПО.
Если компания всерьёз планирует реализовывать IEC 62304, стоит как минимум подумать над включением:
- понятий вроде «артефакт жизненного цикла ПО», «запись о жизненном цикле ПО», «управление конфигурацией ПО», «результаты тестирования ПО»;
- описания, какие записи формируются на каждой стадии разработки (требования, проектирование, верификация, тесты, исправления);
упоминаний об инструментах (таких как Jira, Git, Confluence), через которые ведутся эти записи — даже если на уровне ссылки или примечания;
- того, как эти записи попадают в СМК, кто их регистрирует, кто за них отвечает, и как они проверяются при аудитах.
Без этих дополнений процедура, скорее, относится к "бумажной" СМК, а не к современной инженерной системе управления разработкой программных компонентов медицинских изделий.
👍8🔥1
Коллеги, если вы пишете процедуру по валидации программного обеспечения с целью выполнения требований пунктов 4.1.6, 7.5.6 и 7.6 стандарта ISO 13485, то рекомендую рассмотреть следующее дополнения к определению понятия "программное обеспечение":
Также к программному обеспечению, подлежащему валидации, приравниваются:
− индивидуальные или групповые скрипты, макросы, шаблоны обработки данных (в том числе Excel, Word, Python, R и др.), если они участвуют в критичных для качества процессах;
− агенты искусственного интеллекта (например, голосовые помощники, чат-боты, системы автоклассификации), применяемые в операциях, влияющих на соответствие продукции;
− облачные сервисы с постоянным доступом и обработкой/хранением производственных, проектных, контрольных или регуляторных данных;
− интеграционные платформы, API-шлюзы и другие средства автоматического обмена данными между системами;
− специализированные веб-приложения и личные кабинеты, используемые для взаимодействия с поставщиками или регуляторными структурами, если они участвуют в операциях, влияющих на качество.
Программное обеспечение, установленное на мобильных устройствах (планшетах, смартфонах), под-лежит валидации в случае, если оно используется в производственных, контрольных или вспомогательных процессах, а также в операциях, влияющих на качество продукции или функционирование СМК. К таким случаям могут относиться, например, мобильные приложения для сбора производственных данных, проведения инспекций, контроля параметров окружающей среды или доступа к документации.
Исключение и ПО для валидации: каналы коммуникации, такие как чаты, группы и мессенджеры (например, WhatsApp, Telegram), не подлежат валидации как программное обеспечение, но подлежат регламентации и контролю в рамках процедур управления информацией, в том числе в части защиты персональных и конфиденциальных данных.
Также к программному обеспечению, подлежащему валидации, приравниваются:
− индивидуальные или групповые скрипты, макросы, шаблоны обработки данных (в том числе Excel, Word, Python, R и др.), если они участвуют в критичных для качества процессах;
− агенты искусственного интеллекта (например, голосовые помощники, чат-боты, системы автоклассификации), применяемые в операциях, влияющих на соответствие продукции;
− облачные сервисы с постоянным доступом и обработкой/хранением производственных, проектных, контрольных или регуляторных данных;
− интеграционные платформы, API-шлюзы и другие средства автоматического обмена данными между системами;
− специализированные веб-приложения и личные кабинеты, используемые для взаимодействия с поставщиками или регуляторными структурами, если они участвуют в операциях, влияющих на качество.
Программное обеспечение, установленное на мобильных устройствах (планшетах, смартфонах), под-лежит валидации в случае, если оно используется в производственных, контрольных или вспомогательных процессах, а также в операциях, влияющих на качество продукции или функционирование СМК. К таким случаям могут относиться, например, мобильные приложения для сбора производственных данных, проведения инспекций, контроля параметров окружающей среды или доступа к документации.
Исключение и ПО для валидации: каналы коммуникации, такие как чаты, группы и мессенджеры (например, WhatsApp, Telegram), не подлежат валидации как программное обеспечение, но подлежат регламентации и контролю в рамках процедур управления информацией, в том числе в части защиты персональных и конфиденциальных данных.
👍7👌1
Добрый день коллеги, хочу вернуться к вопросу внедрения требований ISO 9001 на предприятиях занимающихся МИ...
Я выше уже писал некоторые соображения на эту тему, сейчас хочу добавить принципиальный момент связанный с этими двумя стандартами в вопросе проектирования. Прикрепляю здесь слайд который я вставил свою презентацию по обучению СМК. Критикуйте! 😎
Я выше уже писал некоторые соображения на эту тему, сейчас хочу добавить принципиальный момент связанный с этими двумя стандартами в вопросе проектирования. Прикрепляю здесь слайд который я вставил свою презентацию по обучению СМК. Критикуйте! 😎
👍6
В августе на Форуме я проведу семинар о типичных проблемах на инспекциях. Мы разберём реальные случаи, когда требования ISO не совпадают с ПП35/136 и инспекторы трактуют всё по-своему.
Проголосуйте за тему, по которой у Вас было непонимание с инспектором.
Проголосуйте за тему, по которой у Вас было непонимание с инспектором.
Anonymous Poll
55%
управление рисками и изменениями
24%
внутренние аудиты
26%
управление компетенциями
19%
корректирующие действия
31%
обратная связь и жалобы
12%
другое… ☹️ (можете написать в личку?)
🔥5👍3👏1
Коллеги, Извините, но всё-таки похвастаюсь ☺️ Очень интересная формулировка в отзыве попалась 😍
Закончился двухдневный семинар по спецпрограмме составленной самим клиентом . По сути, получилось что-то среднее между семинаром и консультацией...
В свою очередь тоже хочу выразить благодарность всем участникам за интересные вопросы и даже некоторые новые для меня знания которые я непременно вставлю в свой материал.
Закончился двухдневный семинар по спецпрограмме составленной самим клиентом . По сути, получилось что-то среднее между семинаром и консультацией...
В свою очередь тоже хочу выразить благодарность всем участникам за интересные вопросы и даже некоторые новые для меня знания которые я непременно вставлю в свой материал.
🔥10👍3