После нормативной документации, несоответствий, корректирующих действий, жалоб и внутренних аудитов остается еще один большой блок СМК, который часто вспоминают уже ближе к концу обследования: записи качества, регулярный мониторинг целей и показателей, а также анализ со стороны руководства.
На обследовании нужно сразу понять, что должно происходить после появления информации в системе: запись по качеству может просто храниться как подтверждение проверки, показатель - регулярно обновляться под контролем ответственного, а отклонение - запускать разбор причин и дальнейшие действия. Для анализа со стороны руководства к этому добавляются подготовка материалов, принятие решений и контроль их исполнения.
Записи качества: сначала нужно понять, что компания называет записью
Под записями по качеству СМК в разных компаниях понимают совершенно разные вещи: результаты контрольной операции, лист проверки оборудования, журнал температуры, отчет подразделения, результаты испытаний, подтверждение обучения или заполненный контрольный лист. Если перенести все эти материалы в один вид документа «Запись СМК», карточка быстро обрастет десятками реквизитов, которые для большей части записей не имеют смысла.
На обследовании нужно разделить записи по способу возникновения и дальнейшей работе. Для готового файла достаточно документа с понятным видом, периодом и ответственным; если сведения вводятся прямо в 1С:Документооборот, придется определить состав реквизитов для поиска и отчетности; если запись появляется по результату задачи, ее стоит связать с этим действием, чтобы было видно, кто и когда подготовил результат.
Отдельно нужно обсудить периодичность, потому что ежедневный журнал и годовой отчет могут относиться к одной процедуре, но требовать разной автоматизации: сотни отдельных карточек для ежедневных записей будут лишними, тогда как ежемесячный документ с контролируемым сроком уже имеет смысл.
Что спросить по записям качества
- Какие записи СМК ведутся сейчас и какие из них действительно нужно переносить в 1С:Документооборот?
- Где они создаются: в самой системе, в ERP, лабораторной системе, Excel, бумажном журнале или другом источнике?
- Нужно ли хранить сами данные или достаточно файла либо ссылки на источник?
- Кто создает запись, кто проверяет ее заполнение и требуется ли формальное утверждение?
- Как часто возникает запись и есть ли смысл создавать отдельный документ на каждый случай?
- Какие реквизиты потом используются для поиска, отчетности или анализа отклонений?
- Можно ли исправлять запись после завершения проверки и как должна храниться история изменений?
- Что происходит, если запись не создана в срок или содержит отклонение?
Периодический мониторинг нельзя сводить к папке с ежемесячными файлами
Типичная ситуация выглядит так: у подразделений есть ежемесячный/ежеквартальный Excel-файл с показателями, который каждый ответственный обновляет к определенной дате, после чего специалист по качеству вручную проверяет, кто прислал данные, а кому нужно дополнительно напомнить. Если просто перенести эти файлы в общую папку 1С:Документооборота, место хранения изменится, но сама работа останется прежней.
Для такой процедуры нужен не только документ, но и контролируемое действие с ответственным и сроком, поскольку системе необходимо понимать, кто должен подготовить результат и когда он считается просроченным. После выполнения специалист по качеству либо принимает запись, либо возвращает ее на доработку, если данные неполные или заполнены неправильно.
Периодичность нужно настраивать по каждому виду мониторинга отдельно, поскольку часть отчетов появляется ежемесячно, другие - раз в квартал или только после конкретного события.
Цели в области качества не всегда нужно превращать в проекты
Цель вроде «снизить количество рекламаций на 15 процентов» может выглядеть как проект, однако в реальной СМК за ней иногда стоит всего несколько мероприятий и ежемесячный контроль показателя, поэтому создавать полноценный проект с календарным планом ради каждой цели нет смысла. Если цель фиксируется на год, у нее есть ответственный, план мероприятий и несколько контрольных дат, достаточно документа со связанными действиями и периодическим рассмотрением результата.
Проектный механизм имеет смысл тогда, когда достижение цели требует нескольких зависимых этапов, разных исполнителей и контрольных точек. В 1С:Документообороте 3.0 для этого есть план проекта, проектные задачи, вехи и контроль сроков, поэтому крупную программу улучшений уже можно вести как проект.
На обследовании нельзя начинать с вопроса «будем ли заводить цели как проекты». Сначала нужно разобрать, как цель управляется сейчас, сколько действий обычно требуется для ее достижения, кто отвечает за итог, как часто рассматривается прогресс и что происходит при отклонении от планового значения.
Что спросить по целям в области качества
- На какой период устанавливаются цели и кто их утверждает?
- Есть ли у каждой цели измеримый показатель, плановое значение и ответственный?
- Формируется ли отдельный план мероприятий и сколько исполнителей обычно участвует?
- Нужно ли контролировать промежуточные этапы или достаточно итогового значения?
- Как часто руководство рассматривает прогресс и кто готовит данные?
- Можно ли изменить цель или плановое значение в течение периода и кто это согласует?
- Что происходит при отклонении: создается мероприятие, несоответствие, корректирующее действие или только комментарий?
- Требуется ли сохранять историю значений по периодам и сравнивать ее с планом?
Показатель и документ с результатом - не одно и то же
При обсуждении показателей качества может возникнуть мысль спроектировать в 1С:Документообороте расчеты, которые уже существуют в других системах. Например, доля брака может рассчитываться по производственным данным, срок обработки обращения - в CRM, текучесть персонала - в ЗУП, а выполнение поставок - в ERP. Но если переносить исходные операции в 1С:Документооборот только ради СМК, проект быстро выйдет далеко за границы своей задачи.
В 1С:Документообороте в такой ситуации логичнее оставить управленческий слой: полученное значение или отчет, ответственного, факт рассмотрения, решение по отклонению и последующий контроль, тогда как сам расчет продолжает выполняться там, где находятся первичные данные.
На обследовании нужно выяснить источник каждого показателя, потому что фраза «хотим видеть его в СМК» еще ничего не говорит о способе получения. Где-то достаточно ежемесячно приложить утвержденный отчет, где-то имеет смысл настроить обмен, а где-то показатель рассчитывается экспертом вручную и сначала придется договориться о методике расчета.
Красный показатель должен запускать понятное действие
Если мониторинг заканчивается только тем, что значение стало красным в отчете, автоматизация дает мало пользы, потому что ключевой вопрос начинается уже после фиксации отклонения. Нужно заранее определить, какое отклонение требует реакции, кто принимает решение и во что это решение превращается внутри СМК.
Небольшое отклонение можно разобрать на рабочем совещании и назначить одно действие, тогда как повторное или критическое отклонение уже может привести к регистрации несоответствия и анализу причины. Для другого показателя внутренний порядок компании может предусматривать обязательный план мероприятий при любом невыполнении цели, поэтому единое правило для всех показателей здесь редко работает.
Эти условия лучше собрать на обследовании до настройки отчетов, потому что красивый мониторинг без реакции быстро превращается в еще один дашборд, который руководство смотрит раз в месяц, но который почти не влияет на дальнейшую работу.
Анализ со стороны руководства удобно строить вокруг мероприятия
Анализ СМК со стороны руководства - это не просто документ с итогами года, а подготовленная встреча, к которой нужно собрать данные, сформировать повестку, пригласить участников, рассмотреть результаты и зафиксировать решения. Для такой процедуры хорошо подходит механизм мероприятий 1С:Документооборота, поскольку в нем можно работать с участниками, программой, файлами и протоколом, а решения протокола затем передавать на исполнение (как и в случае с внутренними аудитами, которые я разбирала в предыдущей части статьи).
До заседания в мероприятие собираются материалы по жалобам, аудитам, несоответствиям, корректирующим действиям и показателям, после чего решения фиксируются в протоколе. Если по итогам требуется несколько действий с разными ответственными и сроками, исполнение по пунктам позволяет контролировать их отдельно.
Переносить в мероприятие всю историю СМК не нужно: руководителю достаточно подготовленного набора показателей и проблем, а подробная первичная информация остается в связанных документах.
Что спросить по анализу со стороны руководства
- Как часто проводится анализ СМК и кто отвечает за его подготовку?
- Кто определяет повестку и обязательный состав участников?
- Какие материалы должны быть подготовлены к заседанию и кто их предоставляет?
- Какие данные нужно собирать автоматически, а какие остаются экспертными отчетами?
- Какие показатели рассматриваются всегда, а какие включаются только при отклонениях?
- Как оформляется протокол и кто его согласует либо утверждает?
- Какие решения можно исполнить обычными пунктами протокола, а по каким нужно создавать корректирующее действие, несоответствие или отдельный проект?
- Кто контролирует выполнение решений и что происходит при просрочке?
Здесь особенно важна единая классификация
Когда мы подходим к отчетности, ведущейся со стороны СМК, быстро становятся видны ошибки, допущенные при настройке первых процедур (несоответствия, жалобы, улучшения). Если жалобы классифицируются по одному набору подразделений, несоответствия - по другому, а показатели вообще используют свободные названия процессов, собрать нормальный материал для руководства будет сложно, даже если каждая отдельная карточка настроена правильно.
Поэтому на обследовании нужно отдельно проверить общие аналитические разрезы: организацию, подразделение, процесс, направление, продукт, причину и другие признаки, по которым руководство хочет видеть общую картину. Это не означает, что у всех объектов должен быть одинаковый набор реквизитов, однако одинаковые сущности не должны называться и заполняться по-разному только потому, что их проектировали в разные дни.
Не все данные СМК должны рассчитываться в 1С:Документообороте
Желание получить «всю СМК в одной системе» легко превращается в попытку перенести туда производственный учет, продажи и кадровые показатели, которые уже ведутся в профильных решениях. Здесь задача 1С:Документооборота скорее в сохранении управленческого следа: кто предоставил результат, когда его рассмотрели, какое решение приняли и выполнено ли оно.
Если значение можно надежно получать автоматически из другой системы, имеет смысл обсуждать интеграцию; если показатель формируется один раз в квартал и требует экспертного заключения, полноценный обмен может оказаться дороже ручного предоставления отчета. Решение нужно принимать по частоте, объему данных и цене ошибки, а не только по технической возможности интеграции.
Что должно остаться после обследования
По итогам этого блока недостаточно получить перечень отчетов, потому что для настройки нужны связи между записью, показателем, отклонением и управленческим решением. Для каждого регулярного объекта нужно понимать источник данных, периодичность, ответственного, срок, способ проверки и дальнейшее действие при неудовлетворительном результате.
Тогда записи качества перестают быть папкой с файлами, цели - перечнем формулировок на год, а анализ со стороны руководства - мероприятием, после которого остается только протокол. В нормальной схеме значение показателя приводит к решению, решение получает исполнителя и срок, а при серьезном отклонении запускается уже разобранная в предыдущих частях цепочка из несоответствия, анализа причины и корректирующего действия.
Именно на этом месте три части автоматизации СМК соединяются между собой: нормативные документы задают правила, проверки, жалобы и показатели показывают, как эти правила работают, несоответствия фиксируют проблемы, корректирующие действия меняют ситуацию, а анализ со стороны руководства замыкает цикл и определяет, что нужно изменить дальше.