Главная » Хабрахабр » Патологическая анатомия на производстве

Патологическая анатомия на производстве

Продолжаем тему управления качеством, начало здесь.

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

Это какая-то базовая, фундаментальная ценность, цель системы, а не руководство к действию. Определение — понятно, но для управления качеством этого недостаточно. Что делать-то надо?

И качество чего надо повысить? На что направить свои усилия, чтобы повысить качество? В чем разница? Все слышали, что есть качество продукта, а есть – качество процесса. Что важнее?

Оставить качество на месте, а потребителя убедить, что его требования не обоснованы, и ему совсем другое нужно – не то, что он просит. А может, усилия надо направить на требования потребителя? Несложно ведь? Например, убедить покупателя, что колбаса из курицы – лучше, чем колбаса из мяса. Если убедить в этом покупателей, то они изменят свои требования, и качество продукта резко возрастет. Курица – диетическая, жира меньше, легче усваивается, да и стоит дешевле.

Управление качеством? Это что такое получится? Мы не качеством управлять будем, а требованиями. В конечном итоге – да, но путь немного странный. В ИТ, в частности. Есть вроде такая область знаний – управление требованиями? Хотя, если посмотреть телевизор, там только и занимаются, что управлением требованиями – кажется, это «пропагандой» называется.

Попробую рассказать то, что я успел узнать за свою жизнь про «нормальное» управление качеством.

Продукт и процесс

С одной стороны, нам понятна разница между продуктом и процессом. Процесс – это система, или ее часть, которая существует постоянно и производит продукт. Колбаса (конкретная палка) – это продукт. Все, что ее произвело – процесс (оборудование, люди, технология, рецептура, логистика, хранение и т.д.).

Если бывали на заводах — ну, таких, стандартных, обычных заводах, занимающихся какой-нибудь мех.обработкой, то, возможно, оказывались на холиварах между производством и качеством (ОТК, СМК и иже с ними). С другой стороны, эта разница настолько понятна, что при управлении качеством просто упускается из виду. Ребята с производства почти всегда говорят одно и то же: качество – это забота ОТК.

Контролем продукта, т.е. Чем занимается ОТК? Измеряют его, анализы проводят, испытания, и т.д., по результатам которых принимают решение – выпускать (точнее, пропускать) продукт или нет. готового изделия. Если нет – то или в отстойник, или на переделку.

Логика говорит: отлично, ура, мы обнаружили брак, не пропустили его дальше, надо что-то сделать с процессом производства, чтобы ситуация не повторилась. Что происходит на холиваре, когда обнаружен брак? Где-то есть проблемы – с материалами, оборудованием и его настройкой, рабочими, технологией, конструкцией и т.д. Брак ведь не случайно возник? Так ведь, производственники? Надо разбираться, искать причины, думать всем вместе.

Да-да, конечно, мы разберемся, найдем, устраним, все будет хорошо. А те что в ответ? Оформляется соответствующая бумажка, наличие которой вполне одобряет ISO 9001, вроде «акта приема продукции с отклонениями», корректируется для нее рынок сбыта или применение, вроде «хорошему клиенту не отгружать». Вы только брак пропустите дальше, а то у нас план горит. Это еще неплохой вариант развития событий, бывает ведь просто указание сверху – «ОТК, не мешайте людям работать».

А процесс остался на месте. Продукт – конкретный, железку то есть – скорректировали, обеспечили качество, все молодцы, план, премия, корпоратив.

Это долгая, нудная, неблагодарная работа. Возиться с процессом – очень муторно. Это понятная, короткая по длительности, легко измеряемая работа. Исправить продукт – намного проще.

Релиза ПП, автомобиля, письменного стола, моста и т.д. Но выход, или выхлоп от управления качеством продукта почти всегда один – качество одного, конкретного продукта. «Ленни, тащи молоток, тут надо кое-что подправить». Помните, как в Трансформерах было?

И опять ОТК найдет брак. А процесс работает дальше, и продолжает генерировать новые единицы продуктов. И опять все поверят. И опять производство пообещает больше брака не допускать.

Границы продукта и процесса

В реальном производстве определить границы продукта и процесса не очень сложно. Вот колбаса, вот все остальное.

Я прошу прощения, но пример будет про 1С. А как быть, например, в более близком нам примере – работе информационной системы?

Возьмем не методический аспект (как что закрылось), а чисто технический – проведение документа «Расчет себестоимости». Возьмем простой, легко измеримый пример – расчет себестоимости в УПП (кто не знает — это такая программа для управления производственным предприятием, и там есть расчет себестоимости — такая длительная процедура). Определим два показателя качества: провелся или нет, и сколько времени проводился.

То памяти ему не хватит, то из-за блокировок упадет, то сервер 1С зависнет. Первый показатель не всегда актуален, но и такое бывает – вот не проводится, и все. В терминах управления качеством этот показатель называется «альтернативный». Измеряется показателем типа «Булево» — да или нет, провелся или упал.

В терминах управления качеством такой показатель называется «количественный». Второй показатель проще и понятнее – время проведения, измеряется в секундах.

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

Самый простой случай – когда расчет себестоимости не проводится вообще, и вас просят сделать так, чтобы он провелся, хоть как-нибудь. Где здесь процесс, а где продукт? Это означает, что вас просят выпустить продукт, потому что текущий процесс на это не способен вообще – выход годного продукта равен нулю, сплошной брак.

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

Самое простое – выгнать всех пользователей из базы, или работать в только что снятой копии (а потом перенести в рабочую документ со всеми движениями). Например, надо обеспечить отсутствие блокировок на время проведения. Разумеется, надо поставить границу запрета (если ее не было) – это тоже снизит вероятность блокировок. Еще вариант – проводить вне транзакции.

В первую очередь, снять ограничения по памяти на rphost – бывает, что там поставят 1-1. Потом надо сделать так, чтобы сервер 1С не падал. Поэкспериментировать, подобрать подходящее значение можно потом, сейчас от вас требуется продукт, поэтому просто снимаем ограничение. 5 Гб, а расчет себестоимости хочет больше, и процесс, на котором он висит, падает. Пользователей же нет в базе уже.

Обучать бухгалтеров тому, как это делать, объяснять им влияние отрицательных остатков на скорость расчета просто некогда – надо продукт выпустить. Дальше надо убрать отрицательные остатки в регистрах (если расчет идет на РАУЗ). Заодно проверяем, чтобы не было миллиардов в суммах – для этого придется некоторые первичные документы перепровести. Что делать, садимся и исправляем вручную, хотя бы самые вопиющие минусы.

А, да – надо убрать зацикленность в переделах. Так, что еще? Для расчета себестоимости это – зло, потому что многократно растет число узлов. Многие бухгалтера любят комплектациями выпускать продукцию саму из себя, да не по разу.

Но когда это делать? Надо бы, конечно, объяснить им, что так делать нельзя, что надо искать нормальное методическое решение, а не лишь бы проводки сформировались. Надо расчет себестоимости провести. Не сейчас же, правильно? Продукт выпустить.

Ладно, переделываем быстренько комплектации – меняем вид операции с «Комплектация номенклатуры» на «Выпуск продукции», так расчет себестоимости их легче проглатывает.

2 – она постабильнее работает на больших операциях. На всякий случай еще ставим сервер под платформой 8.

Очень долго крутился, но все-таки – получилось! Пробуем – о, провелся! Добьем еще немного, чтобы вау-эффект был сильнее.

Так, что там с косвенными? Видим, что слишком много записей в регистре учета затрат – это плохо. Берем за шкирку главбуха и пробуем выяснить, что там в учетной политике сказано про распределение косвенных. Ну конечно, как всегда – распределяется «все на все», отсюда и огромное количество записей. Вот зарплата АУП цеха № 1 почему падает на весь выпуск всех цехов? Куда какие затраты должны распределяться? Главбух, отвечай, как должно-то быть? А 25-й счет цеха № 2 почему в себестоимости цеха № 3?

Продукт надо выпустить. Главбух, как положено, говорит: должно быть так, чтобы закрылось. Какая структура затрат? Опустел 25 счет – и слава Богу. Все равно экономисты в экселе потом структуру затрат свою клепают, по данным первички, а не по результатам закрытия. Да кто ее смотрит по данным бух.учета?

Объяснить им, что не используют все возможности системы, что вместо учета у них – котел? Ну как, может, совещание собрать? Нет, конечно, не до этого. Что в бумажной учетной политике у них – одно, а на деле – другое? Надо срочно продукт требуемого качества выпустить – чтобы расчет себестоимости провелся, хотя бы, минут за 15.

только на свой выпуск. Ладно, быстренько договариваемся с главбухом об изменении способов распределения затрат – редактируем схемы компоновки так, чтобы косвенные затраты производственных подразделений закрывались «на себя», т.е. И вуаля – записей в регистре учета затрат стало вдвое меньше. Делаем более точным распределение затрат непроизводственных подразделений. Расчет себестоимости проводится за 15 минут.

Продукт выпущен, его качество соответствует требованиям потребителя.

Обратная связь

Вы, возможно, подумали, что так делать не стоит — ну, как я написал выше, упираться и продукт выпускать.

Теперь, поработав над продуктом, ты знаешь, что не так с процессом! А классика управления качеством говорит: отлично, молодец, красава! Давай, беги на вход процесса, и вноси изменения!

На ней основано всем известное «непрерывное улучшение». Это – петля обратной связи, одна из ключевых моделей в управлении качеством. И так – до бесконечности. Увидел проблему в продукте, нашел ее причину в процессе, исправил, посмотрел на результат.

Ну, вроде, понятно – чтобы следующий расчет себестоимости тоже случился, и занял те же 15 минут. Зачем бежать на вход процесса? Что вы будете делать – зависит от контекста.

А может, и рекомендаций не дадите – останетесь уникальным спасителем продукта. Если вы – «призванный» аутсорсер, то ограничитесь рекомендациями, подпишете акт и уйдете.

Причем, с точки зрения карьеры заводского программиста, это будет лучшим решением. Если вы – местный, фикси, то, с высокой вероятностью, тоже «уйдете» — обратно за свой компьютер. Вы ведь уходите победителем, как Зидан из Реала.

Если же скажете «э, не, так дело не пойдет, давайте учет налаживать», то очень быстро превратитесь из победителя в проигравшего – мерзкого зануду, который вечно ноет о том, как все неправильно работают.

Ну и обещания от всех участвующих служб «начать с понедельника новую жизнь». В описанном примере петля обратной связи обычно очень короткая, и никакая она не петля – совещание с разбором ошибок и их причин и план мероприятий по устранению. Ровно так же, как на холиварах производства и ОТК. Реализовывать план уже не нужно, потому что второго совещания не будет.

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

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

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

Приведете-таки настройки распределения затрат в соответствие с учетной политикой, чтобы целью было не «чтобы закрылось», а «получение адекватной оценки себестоимости выпуска, по структуре и суммам».

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

Все ведь известно и понятно, никакой магии. Вроде просто, да? Да нет, конечно. Но будете ли вы это делать? А почему?

Можно, конечно, спорить, но в реальности так и есть. Это никому не надо — таков ведь ответ?

Внимание руководства

Как ни странно, но главная проблема управления качеством – внимание руководства, а точнее – его отсутствие. Об этом и в стандартах ISO 9001 написано, и аудиторы постоянно говорят, и СМК зачастую — самый зачуханный отдел.

В том числе процесса управления. Внимание руководства не к качеству продукта, а к качеству процесса. Но руководство не хочет заниматься процессами, производящими продукт – только самими продуктами.

Плохой, особенно из рук вон плохой продукт – это сигнал, на который руководство реагирует. Вас ведь позвали в тот момент, когда не получалось выпустить продукт, или он был вопиюще плохого качества. Наведение порядка в процессе идет прицепом, и только после того, как исправлен продукт. И акцент делает – исправить продукт. Если его нет, или он сильно низкого качества, его просто не купят – а это уже реальная, понятная и очевидная проблема. Особенно, если это не внутренний, а внешний продукт – тот, что отгружается клиентам.

На брак – не наплевать, потому что это потери. Если поговорить с работниками служб менеджмента качества – откровенно, не на языке лозунгов и стандартов – то они скажут то же самое: руководству наплевать на качество. Не на словах, конечно, а на деле. На процесс, его корректировку и улучшение – глубоко пофиг. Будь то франчайзи 1С, автозавод, производство пакетов или птицефабрика.

Как думаете, в чем они? Последствия такого подхода, на мой личный взгляд, просто ужасающие. Или в том, что куча усилий тратится на исправление продуктов, а не на создание процесса, который исключит брак? В том, что предприятия работают не эффективно?

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

Человек ведь не может уметь то, чего он не делает? Потому что умение управлять качеством атрофируется. Если же, каким-то чудом, задача возникает, то решать ее некому, и задачу приходится хоронить. А не делает, потому что задачи такой нет.

Отсутствие внимания руководства становится шикарной отмазкой для менеджеров качества – никому не надо, вот мы и не делаем.

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

Смутно понимаем, что виноват процесс. Знаем, что с качеством проблемы. Результат-то один — не будем. Построить логическую цепочку от следствия к причине не можем, или не хотим, или не дают, не важно. Внедрить какое-нибудь готовое решение! И что тогда делать?

В управлении качеством набор стандартный – ISO, 5S, 6 sigma, Lean (бережливое производство). За примерами далеко ходить не надо. А оно будет? Бери стандарт, делай, что там написано, и будет тебе счастье. Счастье наступило? У вашей компании есть сертификат ISO?

Чем не таблетка? Или внедрение информационных систем, типа ERP. Или только новые создает? Решает оно какие-нибудь проблемы? Вам нужен Scrum. Вам нужен ТОС. Вам нужна белковая диета. Вам нужны KPI. Вам нужно пиво Клинское. Вам нужно бегать по утрам.

Внедряется не то, что улучшит процессы, а то, что наверное улучшит процессы. Не важно, что именно. Просто вслепую лупим по процессам, как из пушки по воробьям, и бежим смотреть на результат. Невзирая на фактические показатели, причины и следствия. Ну, наверное, рукожопые из нас артиллеристы менеджеры качества. Нет результата?

Точно не знаем, что надо сделать, но делаем хоть что-нибудь. Вообще, попытки хоть что-то изменить, даже вслепую – это уже неплохо. Некоторые ведь вообще ничего не меняют в системе.

А, нет, там ведь тоже обратная связь нужна — поглядеть в бинокль, куда попал, и скорректировать прицел. Если несколько раз вслепую бабахнуть, то, может, и стрелять научимся? Так что, увы.

Резюме

Принципиально можно управлять: качеством продукта, качеством процесса, требованиями потребителя.

Остальные единицы продукта остаются без изменений, равно как и процесс их производства. Управление качеством продукта – это воздействие на конкретную единицу выпускаемой продукции или услуги.

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

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

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

Так задумано изначально. Собственно, «управление качеством» — это управление качеством процесса.

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

Если кто-то говорит, что управляет качеством, но не вносит изменений в процесс – есть вероятность, что он… ну это… неправду говорит.


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Big data, deus ex machina

Источник Эту фразу на выступлении для PopTech произнёс несколько лет назад Джер Торп (Jer Thorp), художник и эксперт в вопросах анализа и визуализации данных, один из основателей «Бюро креативных исследований». «Данные — это новая нефть». Разбираемся, какие данные big, а ...

XXH3: новый рекордсмен по скорости хеширования

Бенчмарки сделаны в программе SMHasher на Core 2 Duo 3,0 ГГц Они применяются там, где важна скорость и нет смысла применять медленные MD5 или SHA1. На Хабре неоднократно рассказывали про некриптографические хеш-функции, которые на порядок быстрее криптографических. Например, для построения ...