Сегодня мы снова рассмотрим вопрос по теме, предложенной подписчиком - постоянное улучшение СМК. Параллельно, на примере локальных нормативных документов СМК я постараюсь немного рассказать про цикл Шухарта-Деминга, известный всем как цикл PDCA.
Поехали! )
1. Процессы
Для того, чтобы говорить об улучшениях, мы должны сначала еще раз понять, что же мы хотим улучшать. Как мы с вами уже знаем, основные строительные кирпичики СМК - это процессы (если вы еще не знаете, что это, то вот статья на эту тему).
Как мы помним, в самом общем случае, процессы состоят из:
- входов;
- выходов;
- управляющих воздействий;
- ресурсного обеспечения выполнения процессов.
И вот тут нам важно определиться с тем, что из всего этого мы можем улучшить. Для начала возьмем "сферический процесс в вакууме", то есть, будем считать, что у нас всего один процесс, и он ни с чем другим не связан.
Это упрощение сделано только для примера, так в реальности не бывает.
Тогда смотрим.
Можем ли мы повлиять на входы процесса? В заданных условиях - вряд ли, ведь входы приходят в процессы извне, по условиям задачи, т.к. процесс у нас один, то мы не можем управлять тем, что порождает входы нашего процесса.
В качестве утрированного примера могу привести только немотивированное желание чего-либо =) Вот хочу и пусть весь мир рухнет! Не важно чего хочу, каждому свое. Кому-то любви, кому-то машину, кому-то в космос полететь. Главное, что вещи на входе процесса не находятся под нашим управлением, они просто есть, и они таковы, каковы есть и не более.
Можем ли мы повлиять на выход процесса? Да, в этом ведь и задача улучшения!
Но не напрямую. Потому что, как мы помним, процесс - это совокупность действий по преобразованию входов в выходы. То есть, мы влияем на качество выхода процесса за счет изменения качества переработки входа процесса.
Другими словами, если мы делаем котлеты, то при заданном входе процесса (сырье) на качество котлет будет влиять то, как мы сырье обработаем, как приправим, как пожарим, как руки помоем перед тем, как за сырье браться, в конце концов. Но вот щелкнуть пальцами и сказать "Ща будет красиво" у нас вряд ли выйдет.
Те, кто уже мыслит процессным мышлением скажет мне, мол, качество входов (сырья) уже воздействует на качество выходов (котлет). Конечно! Но пока что мы рассматриваем сферический процесс в вакууме, а про концепцию внутреннего потребителя можно почитать вот тут.
Итак, у нас остаются ресурсы процесса и управление им.
Те, кто работает в системе знают, что на уровне СМК управлять ресурсами организации довольно сложно. По мановению волшебной палочки вам вряд ли добавят штат в нужное подразделение или улучшат финансирование. Это все должно быть жестко обосновано, желательно с цифрами в руках, выраженных в рублях недополученной прибыли или потенциальных потерь при условии работы по-старому. Поэтому я для целей данной статьи приму ресурсы условно управляемыми.
Кроме того, и это очень важно, если мы ставим перед собой задачу повышения качества процессов, то такой показатель, как ресурсоемкость процесса должен снижаться. Об уровнях качества и связанных с этим затратах ресурсов я писал вот тут.
Что у нас остается? Правильно, управление процессами. Вот тут у нас наступает самый простор для плодотворной работы, т.к. организация управления процессами - это самый наш СМК-шный хлеб.
2. Управление процессами
В этом разделе мы поговорим о механизмах управления процессами и выясним, почему эти механизмы не являются "гранитом, с чьих-то слов отлитым".
Процессы в организации могут управляться двумя способами:
- "Вашу мать, бегом, я сказал, от забора до обеда копать!"
- локальными нормативными документами (ЛНД) организации.
Первый способ отсекаем как непродуктивный, хотя подходящий для кризисного управления. Поговорим про ЛНД, о том, что это такое, я писал вот в этой статье.
Ход любого процесса должен быть детализирован соответствующими ЛНД организации. При этом, ЛНД могут быть разделены на разные иерархические уровни для различных уровней управления. Например:
- Стандарт - устанавливает общий ход процесса и ответственность должностных лиц верхнего уровня;
- Положение - устанавливает детализированный ход подпроцесса или процедуры;
- Инструкция, Методические указания, Регламент - регламентируют выполнение процесса/процедуры на уровне исполнителя (токаря, технолога, стенографистки и т.д.)
Все это определяет организация сама для себя. Кому-то достаточно в Стандарте описать весь ход небольшого процесса, а у кого-то один процесс будет описан в нескольких томах ЛНД.
Мое главное требование к ЛНД, регламентирующим бизнес-процесс, это чтобы из документов было понятно КТО, КОГДА, КАК должен что-то сделать, каковы его ПОЛНОМОЧИЯ в процессе и какова его ОТВЕТСТЕННОСТЬ при выполнении процесса.
Ну, об этом уже было много сказано, повторяться не буду. Сейчас мы говорим об улучшениях. А что такое улучшение?
Как мы договорились выше, влиять мы можем пока что только на управление процессом, т.е. на ЛНД, регламентирующие данный процесс. Если мы хотим улучшить ЛНД - значит должен быть механизм внесения в них изменений или их актуализации путем переиздания, отмены и т.д. В любом случае, эти шаги должны быть направлены на улучшение всей системы.
Собственно, об этом подписчик и просил рассказать, давайте на практике посмотрим, каким образом методически правильно вносить изменения в фонд ЛНД организации.
2.1 Разработка/актуализация ЛНД
Главное правило хорошей СМК. Разработку/актуализацию ЛНД по своему направлению деятельности осуществляют те, кто организует и реализует данное направление деятельности.
То есть, не вдаваясь в понятия "Менеджер ЛНД" или "Владелец ЛНД", можно сказать так: ЛНД по закупкам разрабатывает отдел закупок. ЛНД по направлению обслуживания зданий разрабатывает отдел по обслуживанию зданий.
Каждый из нас, будучи на своем месте, свою работу знает лучше других. Поэтому попытки переложить разработку/актуализацию ЛНД, например, по сопровождению договоров, на отдел СМК я считаю порочной практикой.
Впрочем, мы у себя даже согласились на это, при условии, что профильные специалисты согласуют нашу редакцию ЛНД, не читая финальный результат. Пока что из профильных никто не согласился на наши условия =)
Основанием для разработки/актуализации ЛНД могут быть (включая, но не ограничиваясь):
- требования законов, государственных и международных нормативных, технических и иных актов;
- требования акционеров вашей организации (при наличии);
- требования надзорных органов;
- внутренняя потребность в регламентации процессов или в их улучшении.
Вот на последнем пункте мы и остановимся, т.к. прочие основания обычно являются "железобетонными".
Хорошо, когда вы можете найти общий язык с владельцем нужного процесса и договориться с ним о разработке или актуализации нужного ЛНД, понимая, что в этом есть потребность. Адекватные владельцы ЛНД обычно понимают эту необходимость сами, т.к. им самим становится неудобно работать без документов или с устаревшими документами.
Если же полюбовно не выходит, то, например, ГОСТ РВ 0015-002 требует наличия на предприятии совещательного органа при руководителе, который рассматривает вопросы качества, вопрос о необходимости разработки/актуализации ЛНД может быть вынесен на такое совещание.
Можно выйти с инициативой путем направления докладной на имя руководителя с просьбой дать поручение профильному структурному подразделению (СП) проработать вопрос по его ЛНД.
Вариантов много. Главное - должно быть основание для изменения документации - вы же предлагаете не просто переписать бумагу, а изменить порядок работы подразделения, а то и не одного подразделения, если в процессе задействовано их несколько.
Считаем, что мы обоснованно добились разработки/актуализации ЛНД. И вот теперь на руках у разработчика ЛНД есть его проект. Следующая ступень - согласование.
2.2 Согласование проекта ЛНД
Процесс согласования проекта ЛНД очень важен, т.к. на этом этапе производится "увязка" новых требований с другими подразделениями, задействованными в процессе, с другими действующими ЛНД других подразделений. Ведь автор ЛНД по закупкам, в которых участвует производственное подразделение, вполне может не знать в совершенстве процессы производства, помним? ))
В моей модели, которая работает у нас на предприятии, ЛНД подлежит согласованию со всеми его исполнителями. Это идеально, ведь, человек, согласовавший документ, не сможет уже отказаться от его исполнения.
Однако, этот подход тоже нуждается в переработке, видите, я тоже улучшаю нашу систему в меру сил. Проблема "всех заинтересованных" состоит в том, что не все ЛНД следует согласовывать всеми участниками процесса. Технически это очень сложно. Сейчас я думаю над разделением документов по уровням согласования.
Документы типа "Положения об оплате труда" не должны проходить согласования со всеми на предприятии, достаточно небольшого количества лиц, касающихся оплаты и профсоюза работников.
А вот документы типа "Инструкция по выпуску и прохождению заказ-нарядов" уже должна быть согласована со всеми ее исполнителями, благо, их не так много, и процесс жестко регламентирован.
В общем, надо в каждом случае думать отдельно.
Но в любом случае, согласование документов должно быть подтверждено документально. Обычно, выпускается лист согласования по форме, утвержденной в Обществе. Объем согласования выбирает разработчик ЛНД и несет за это ответственность.
После утряски всех спорных моментов и получения всех нужных подписей в листе согласования наступает финальный этап данной работы.
2.3 Утверждение и введение в действие ЛНД
Важно! Каждый ЛНД мало ввести в действие. Его перед этим необходимо утвердить.
Утверждение ЛНД производит то должностное лицо, в чью компетенцию это входит. Например, устав Общества утверждает Совет директоров, Стандарт организации утверждает ЕИО Общества, а инструкцию по безопасной эксплуатации станка может утвердить главный инженер.
Документ можно ввести в действие только после его утверждения.
Вводится в действие ЛНД распорядительным документом организации (распоряжением, приказом).
Соответственно, в приказе должны быть соответствующие формулировки. Например, документ утвержден советом директоров и вводится в действие приказом, тогда:
...На основании протокола заседания общего совета директоров от 12.02.2034 года №233
ПРИКАЗЫВАЮ
1. Ввести в действие ЛНД.......
2. Ответственность за реализацию требований ЛНД.... в Обществе возложить на...
3. Ответственность за поддержание ЛНД.... в актуальном состоянии возложить на.....
Если ЛНД утверждается и вводится в действие приказом ЕИО, то можно вот так писать в приказе:
В целях оптимизации процесса.... [структурным подразделением] был разработан (актуализирован) ЛНД.... С целью введения в действие указанного ЛНД
ПРИКАЗЫВАЮ
1. Утвердить и ввести в действие ЛНД....
2. Ответственность за реализацию требований ЛНД.... в Обществе возложить на...
3. Ответственность за поддержание ЛНД.... в актуальном состоянии возложить на.....
С распоряжением главного инженера то же самое.
Если ЛНД актуализируется, то это можно сделать путем внесения в него изменений, а можно путем замены, тогда так и пишем в приказе (распоряжении):
1. Утвердить и ввести в действие изменения в ЛНД... согласно приложению к настоящему приказу (распоряжению)
или
1. Утвердить и ввести в действие ЛНД....
2. ЛНД, утвержденный и введенный в действие приказом от ХХ.ХХ.ХХХХ №ХХХ считать утратившим силу
ВАЖНО!
Меня очень бесит, когда управляющая организация (в нашем случае) присылает нам утвержденный ими ЛНД с формулировкой в приказе нам "1. Утвердить данный ЛНД в Обществе". Бараны, вы его уже утвердили у себя, мы можем только ввести его у себя в действие.
Эти формулировки юридически значимые, старайтесь избегать данных ошибок.
С момента выхода приказа (распоряжения), если в нем не указано даты, с какой ЛНД считается введенным в действие, новый ЛНД считается действующим.
Нюансов тут масса, и все они должны быть описаны у вас в организации в документе по процессу разработки/актуализации ЛНД.
3. Цикл Шухарта-Деминга
А теперь буквально чуть-чуть про цикл PDCA. Мы с вами знаем, что это - Plan-Do-Check-Act, то есть, Планируй-Делай-Проверяй-Корректируй.
В работе с ЛНД этот подход наиболее наглядно смотрится.
Допустим, есть описанный процесс, он работает, но криво-шатко, и все это видят.
Планируем переработку ЛНД, управляющего этим процессом. Перерабатываем. Наблюдаем за его реализацией, ищем "косяки". Корректируем ЛНД. Планируем переработку и т.д.
Процесс итерационный, с каждой итерацией (повторяющимся этапом доработки) мы становимся ближе к комфортному течению процесса для всех его участников.
Простой пример: Не было у вас процедуры входного контроля продукции, возникла потребность, написали процедуру, начали по ней работать. Тут неудобно, там не так. Подумали, доделали процедуру, снова в работу ее взяли. Вроде все хорошо, но приехал аудит и сказал, что вот тут вы неправы, ок, доделали, снова обкатали в работе. Прошло 2 года и вы про ЛНД по входному контролю забыли, процедура работает автоматически ) Вот в этом и есть суть )
Надеюсь, не сильно заморочил вам мозги ) Тема-то обширная, одной статьей не обойтись )
P.S. А теперь уйдем от "Сферического процесса в вакууме" и представим себе цепочку процессов, где выход каждого - это вход следующего. Как повысить результативность следующего процесса? Улучшить выход предыдущего. Концепция внутреннего потребителя. А как улучшать процессы - мы теперь знаем ))
Темы для новых статей я собираю в комментариях к этой ветке, милости прошу!
