Управление несоответствиями: задачи, подходы и автоматизация

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

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

Сначала фиксируют проверяемый факт и защищают процесс от распространения отклонения; гипотезу причины разбирают после локализации риска.

Что считается несоответствием

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

Примеры:

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

Важно отделять факт от предположения о причине. Формулировка «оператор невнимателен» уже содержит вывод, а «в записи отсутствует обязательное значение» описывает проверяемое отклонение.

Несоответствие, дефект, инцидент и жалоба

Один случай может иметь несколько связей. Жалоба клиента может подтвердить несоответствие продукции, которое затем запускает корректирующее действие и влияет на оценку поставщика.

Две ветки решения: объект и система

Переделка или возврат решают судьбу конкретного объекта; изменение процесса снижает вероятность повторения подтверждённой причины.

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

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

Закрытие допустимо, когда решение по объекту исполнено, а системная ветка либо принята и проверена, либо есть зафиксированное основание, почему она не требуется. Это разграничивает управление конкретным несоответствием и полноценный процесс CAPA: связанный материал о CAPA рассматривает портфель корректирующих и предупреждающих действий шире, а здесь центральным объектом остаётся зарегистрированное отклонение.

Коррекция и корректирующее действие

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

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

Как анализировать причины

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

Полезно рассматривать:

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

Фраза «человеческий фактор» редко является достаточной причиной. Нужно выяснить, почему система позволила ошибке возникнуть или остаться незамеченной.

Роли и решения

Регистратор описывает факт и прикладывает доказательства. Владелец процесса или качества классифицирует случай и назначает рассмотрение. Эксперты оценивают технические последствия. Ответственные за действия выполняют меры, а независимая проверяющая роль подтверждает результат.

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

Карточка несоответствия

Показатели процесса

Количество зарегистрированных случаев нельзя автоматически считать показателем плохого качества: рост может означать улучшение выявления. Метрики нужно рассматривать вместе.

• число несоответствий по типу, объекту и источнику;
• распределение по критичности;
• время до локализации и итогового решения;
• доля просроченных действий;
• частота повторных случаев;
• доля мер, не прошедших проверку эффективности;
• затраты на переделку, списание и претензии;
• поставщики, процессы и участки с устойчивыми отклонениями.

Связь с поставщиками и аудитами

Если причина связана с поставщиком, случай должен влиять на его историю и оценку. Поставщику направляют запрос на анализ и действия, а подтверждение рассматривает ответственная роль заказчика. Закрытие претензии и закрытие внутреннего несоответствия могут иметь разные сроки.

Результаты аудита также удобно связывать с общей системой действий. Это позволяет увидеть, какие замечания повторяются, какие процессы создают риск и насколько своевременно выполняются меры.

Автоматизация управления несоответствиями

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

На базе Comindware Platform можно настроить формы, маршруты, правила, уведомления и аналитику под действующую систему качества. При изменении регламента процесс и набор данных можно развивать без замены всего решения.

Чек-лист запуска

1. Определите типы несоответствий и источники требований.
2. Согласуйте шкалу критичности и правила немедленных мер.
3. Разделите коррекцию, анализ причины и корректирующее действие.
4. Назначьте роли регистрации, расследования и закрытия.
5. Настройте критерии проверки эффективности.
6. Свяжите случаи с объектами, поставщиками и аудитами.
7. Добавьте сроки, уведомления и эскалации.
8. Проведите пилот на одном процессе и уточните классификаторы.

Частые вопросы

Нужно ли регистрировать каждое отклонение?

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

Когда нужен анализ коренной причины?

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

Кто может закрыть несоответствие?

Уполномоченная роль, которая может проверить полноту действий и доказательства результата. Для значимых случаев полезна независимость от исполнителя мер.

Что такое CAPA?

Это система корректирующих и предупреждающих действий. В контексте выявленного несоответствия основное внимание уделяется устранению подтверждённой причины и проверке эффективности.

Как контролировать просроченные действия?

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

Можно ли работать с несоответствиями поставщиков в той же системе?

Да. Полезно связать случай с карточкой поставщика, поставкой, претензией и оценкой, сохраняя отдельные права доступа для внешних участников.

Похожие записи:

Итоги конференции CNews «Роботизация бизнес-процессов 2021» 3 мифа о BPM и BPMS Нотация BPMN 2.0: ключевые элементы и описание Comindware — Один из Первых Успешных Выпускников Сколково 2021