Идеология порядка
публикация - 2016-06-08 cоздание - 2014-07-15
6.2.1. «Встроенное качество» TQM ч.4
Пазл сложился
Для тех, кто занимается управлением технологией, важно максимально быстро найти причину отклонений. А это зачастую является не такой простой задачей. И не сколько из-за «отсутствия мозгов» сколько из-за организационных проблем. Тем более что при должной организации работ особой интеллектуальной подготовки не требуется.
Суть любого анализа заключается в сопоставлении событий. Если есть согласованные изменения, то у нас крепнет предположение, что между событиями есть связь. И если эта связь не случайная, то можно говорить о причинах и следствиях. Вот такая вот простая технология поиска причин, но не такая простая в реализации.
В реальной системе существует много участников процесса, у каждого из которых свои интересы. И часто эти интересы идут в разрез с прозрачностью. Не все заинтересованы в отображении проблем, дефектов, брака. Но, не видя проблему, не решишь ее.
Когда проблем много, первый порыв - усилить внешнее управление и контроль, но тем самым формируется сложные иерархичные системы, в которых управленцы и контролеры отвечают за выделенный ему кусочек технологии. В результате появляются межфункциональные барьеры, которые мешают в выполнении на самом деле несложного анализа по поиску причин дефектов. Почему несложного? Если есть достоверные данные, и вы в реальном режиме времени видите значимые отклонения в дефектах, то пока «следы не замело», можно быстро и просто найти причину в потоке производства.
Есть и еще одна системная проблема - отсутствие реальной работы по стандартам. Мы можем сегодня найти причину отклонения, решить ее и забыть как плохой сон. А через полгода опять споткнуться об нее и повторить пройденный путь. Так можно бесконечно наступать на грабли.
Если решить проблему прозрачности, убрать межфункциональные барьеры, внедрить стандартизированную работу, то можно реализовать простую, но эффективную «технологию управления технологией». Совсем недавно предложил инженерам технологам разработать такую простую технологию управления при условии, что вышеперечисленные системные проблемы решены. Так вот опытные технологи в течение двух месяцев разрабатывали схему работы для нового типа специалиста, инженера процесса. Она должна была позволять в реальном режиме времени осуществлять работу с отклонениями, оперативный поиск причин и встраивание лучших решений в стандарты. Сначала принесли сложные схемы, со сложными согласованиями, с совещаниями, c формированием каких-то программ. В них четко прослеживалось нежелание брать на себя ответственность за ведение технологии, они ее постоянно хотели с кем-то разделить. Пришлось поработать в этом направлении. Убедить, что никто кроме них их проблемы не решит. Убедить в том, что прежняя методология работы с технологией уже не соответствуют текущим реалиям. Условия изменились, требуется персональная ответственность за качество. Приняв такой поворот за факт, сформировали простую, но эффективную блок схему работы инженера процесса. По сути это и есть «технология управления технологией».
Реагируем только на значимые отклонения критических параметров. Это важно понять и принять. Если у вас стабильно идет процент дефектов, то не вмешиваемся в процесс. Но как только произошло устойчивое значимое отклонение или в худшую, или в лучшую сторону – это сигнал для начала анализа. Именно это указывает на то, что произошел нетиповой, нестандартный случай в работе исполнителей. Его и надо «поймать». Вот так просто. Если у вас хороший информационный поток, то скачек на выходе процесса легко отслеживается по скачку параметров или действиям оператора в процессе. Если информационный поток слабый, то остается одно - ножками идти с конца потока до начала и осуществлять сбор информации от рабочих.
Ищем причину по горячим следам. Экспертов привлекаем только в крайнем случае. Даже если у вас хорошая информационная система, в ней отражена не вся информация. Далеко не вся. Поэтому важно, когда происходит значимое изменение в дефектах осуществлять поиск причин сразу, пока еще возможно «взять». То, чего нет в информационной системе, можно «вытащить» из рабочих. Особенно тогда, когда у вас с ними выстроена хорошая коммуникация. Как показывает опыт, комбинация анализа данных из информационных систем и от исполнителей процесса, дает максимальный эффект.
Если анализ значимых отклонений в дефектах осуществляется постоянно, то вероятность оперативного нахождения причин существенно возрастает. И для этого не надо экспертов, с такой работой справится «рядовой» инженер технолог. Конечно, если он будет работать в приведенном ключе. Что касается экспертов, то к их помощи надо прибегать только в крайних случаях. Во-первых, внешний эксперт не знает в деталях технологию, во-вторых, надежда на дядю «расслабляет» технологов, ну и в третьих должна быть элементарная профессиональная гордость: проблемы должны решать сами.
Не делаем работу за рабочих, а стандартизируем ее. Каждый должен заниматься своим делом, рабочий должен исполнять стандарты, инженер процесса искать причины значимых отклонений и стандартизировать процесс, чтобы они в будущем не появлялись. Это принцип. Не надо за рабочего делать его работу.
Стандарт должен быть исполнимым. Если причина значимого отклонения дефектов найдена, то здесь надо разделить два события: либо нет стандарта, исключающего дефект; либо стандарт не исполняется. Важно, чтобы стандарт был исполнимым. Это честно по отношению к рабочему. Если стандарт исполнимый, но его не выполняют, у вас есть право административного воздействия. А для того, чтобы он был исполнимым важно разработку или совершенствование стандарта осуществлять совместно с исполнителями процесса.
Если стандарт не работает, совершенствуем его. Бывает и так, что стандарт есть, он исполнимый, а дефекты идут. Значит, стандарт не работает, его надо совершенствовать. А для этого могут потребоваться другие подходы и методы. Для этого надо взглянуть на процесс шире.
Если рабочий не знает стандарт, обучаем. Можно конечно и не обучать, а сразу наказать в случае неисполнения стандарта. Но тогда у нас не будет нормального диалога с рабочим. А он нам необходим как для поиска причин проблем, так и для совместной разработки стандартов. Кроме того, чисто по человечески, если есть стандарт, то нужно обучать. Где-то добрым словом, а где-то и крепким.
Если рабочий знает стандарт, но не исполняет его, то нужно принимать жесткие меры. Это принцип дисциплины. Нельзя прощать за неисполнение стандарта депремированием. Мы сделали все по-человечески: вместе нашли причину проблемы, вместе разработали стандарт, обучили. В этом случае, если стандарт не исполняется, то это говорит о безответственности человека. Лучше с такими людьми своевременно прощаться. Иначе от этого будут страдать другие.
Командная работа. Одна голова хорошо, а две лучше. А если есть команда, то любую проблему можно решить. Работа со значимыми отклонениями должна осуществляться постоянно. Если процесс динамичный, то каждую смену. Четыре смены, четыре инженера процесса. Для эффективной их работы они должны быть сформированы по командному принципу. Команда – это три-пять человек. У нее есть лидер. Лидер и члены команды имеют общую ответственность. Командную ответственность. Деятельность в команде должна быть прозрачна. Результаты одного влияют на результаты другого. Так вот 4+1 - четыре инженера процесса + лидер. Лидер лучший инженер процесса. Ответственность - качество. Прозрачность – общая информационная среда и развитая коммуникация.
Приведенная «технология управления технологией» упрощает и одновременно повышает эффективность анализа, направлена на постоянное совершенствование стандартов, формирует качественно новую производственную культуру. Культуру работы по стандартам. Читать далее...
Все материалы раздела...
Сайт ssman.ru: люди сильные духом. Количество посещений=95939