Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Categories:

Системы менеджмента качества, системы техрегламентов, прочие "системы" вокруг производства

1. Система обеспечения качества относится к системе норм (в смысле тезисов http://ailev.livejournal.com/510186.html). Это один из многих источников норм, используемых при планировании работ, среди других можно указать:
-- собственно технологические нормы -- "что нужно делать", как достигнуть цели
-- нормы технического регулирования (безопасности) -- как нужно делать то, что нужно делать для достижения цели, чтобы удовлетворить ограничениям безопасности
-- нормы качества (достижения неизменно превосходного результата) -- как нужно делать то, что нужно делать для достижения цели, чтобы удовлетворить ограничениям стабильности (предсказуемости) производства по уровню возможных дефектов/сбоев

2. Проблема в том, что:
а) производство работ устроено пошагово с точки зрения отдельных исполнителей. Это процедурный подход, это отражено в действительности планирования.
б) нормы заключаются в документах, которые действуют все одновременно.
Тем самым исполнитель должен "выполнять мероприятия по обеспечению технологии, качества, безопасности" в действительности планирования и исполнения работ, а сами мероприятия описаны в трех разных стопках документов. Работник (скажем, монтажник в инжиниринговой компании) должен как-то самостоятельно делать слияние трех пошаговых процедур в одну, что для него явно непрофильная мыслительная операция.

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

4. Тем самым на разных полках хранятся три комплекта документов с различными наименованиями (регламенты производства работ, технические регламенты, требования системы менеджмента качества), плюс некоторое количество описаний закопано в workflow-описаниях различных IT-систем (документооборота, ERP и т.д.).

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


6. Корни этой системы в том, что каждый "управитель" (технологией, безопасностью, качеством) мыслит себя отдельной управляющей инстанцией и требует собственных наименований документов. Поэтому доходит до таких забавностей, как несколько "почти одинаковых" пачек документов, появляющихся из-за наличия нескольких "почти одинаковых" регуляторов одного и того же аспекта деятельности.
Пример из Федеральных Норм и Правил в области использования атомной энергии НП-011-99, утвержденных постановлением Госатомнадзора России от 21.12.1999г.N4:
"В случае, если эксплуатирующая организация АС и (или) организации, выполняющие работы и предоставляющие ей услуги, внедрили систему качества согласно международным стандартам ИСО серий 9000, что документально оформлено, то программа обеспечения качества для АС может содержать ссылки на соответствующие элементы системы качества и описания дополнительных процедур обеспечения качества".
Это означает, что на предприятии будут две пачки документов, обеспечивающих качество: одна пачка "международного стандарта", а вторая пачка -- ссылок на документы первой пачки (фактически "переименования документов"), плюс дополнительные процедуры.


7. Что нужно делать?
а) понять, что система управления нормами -- одна, а не разные для разных "управителей"
б) признать наличие разных источников норм
в) не требовать создания специальных документов со специальными названиями для разных "управителей", требовать только учета требуемых разными "управителями" норм в системе управления нормами (т.е. требования должны быть к идеальным объектам -- нормам, а не "реальным объектам" -- документам). Это означает, что нормы обеспечения качества должны быть утверждены и использоваться в деятельности. А вот будут ли они оформлены отдельными документами СМК или будут включены в другие "пачки документов" -- это дело десятое. Т.е. норма качества необязательно должна утверждаться именно как "норма качества" отдельным документом, и исполнение ее не должно проверяться по тексту этого отдельного документа.
г) софт по работе с нормами должен лего композировать-декомпозировать нормы из их обстоятельств, предписаний (т.е. гипотез, диспозиций) и санкций. Софт по работе с нормами также должен обеспечивать легкость процедуры "свода" (т.е. разбиение документов на отдельные нормы и сборку из отдельных норм тех или иных документов -- а то и не из норм, а из их обстоятельств, предписаний (гипотез, диспозиций), санкций -- в том числе получение процессных регламентов вплоть до уровня "технологических карт" или "типовых проектов".
д) софт по работе с планами должен обеспечивать легкость генерации норм или их частей (прежде всего -- предписаний, "процессов") из планов путем их всевозможной параметризации. Далее из этих норм можно будет при необходимости издавать регламенты (утвержденный документ, предписывающий выполнение "процесса" в указанных обстоятельствах).
е) сами нормы нужно разбить на "обязательные", "рекомендуемые" и "рабочие" -- и все их иметь в одной системе, чтобы не разрушать единство системы нормирования работ. Ибо все эти "дополнительные процедуры" чаще всего относятся к случаям, когда нужно вставить что-то "обязательное" для одного управителя в "рабочее" для другого. Эти "рабочие нормы" (не зафиксированные нигде) записываются в обстоятельства, а предписание содержит кусок "процедуры", который должен быть вставлен между не отраженными нигде (или отраженными в пачке технологических документов) шагами "рабочего процесса". Результат тут выглядит так, что в "необязательном" процессе вдруг появляется "обязательный" кусок, за выполнением которого присматривает отдельная группа проверяющих.

То есть все эти "системы качества", "системы техрегулирования" -- это не системы вовсе, границы их неправильно определены, формозадающие факторы выбраны неверно. Отсюда и беды: непрекращающиеся попытки сделать "систему дырки от бублика" рядом и независимо от самого бублика.
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 26 comments