Патологическая анатомия на производстве
Продолжаем тему управления качеством, начало здесь.
Что такое качество — допустим, разобрались, это степень соответствия требованиям потребителя. Вы, возможно, не согласны, по крайней мере с моей категоричностью, но вроде явных ляпов в этом определении нет.
Определение — понятно, но для управления качеством этого недостаточно. Это какая-то базовая, фундаментальная ценность, цель системы, а не руководство к действию. Что делать-то надо?
На что направить свои усилия, чтобы повысить качество? И качество чего надо повысить? Все слышали, что есть качество продукта, а есть — качество процесса. В чем разница? Что важнее?
А может, усилия надо направить на требования потребителя? Оставить качество на месте, а потребителя убедить, что его требования не обоснованы, и ему совсем другое нужно — не то, что он просит. Например, убедить покупателя, что колбаса из курицы — лучше, чем колбаса из мяса. Несложно ведь? Курица — диетическая, жира меньше, легче усваивается, да и стоит дешевле. Если убедить в этом покупателей, то они изменят свои требования, и качество продукта резко возрастет.
Это что такое получится? Управление качеством? В конечном итоге — да, но путь немного странный. Мы не качеством управлять будем, а требованиями. Есть вроде такая область знаний — управление требованиями? В ИТ, в частности. Хотя, если посмотреть телевизор, там только и занимаются, что управлением требованиями — кажется, это «пропагандой» называется.
Попробую рассказать то, что я успел узнать за свою жизнь про «нормальное» управление качеством.
Продукт и процесс
С одной стороны, нам понятна разница между продуктом и процессом. Процесс — это система, или ее часть, которая существует постоянно и производит продукт. Колбаса (конкретная палка) — это продукт. Все, что ее произвело — процесс (оборудование, люди, технология, рецептура, логистика, хранение и т.д.).
С другой стороны, эта разница настолько понятна, что при управлении качеством просто упускается из виду. Если бывали на заводах — ну, таких, стандартных, обычных заводах, занимающихся какой-нибудь мех.обработкой, то, возможно, оказывались на холиварах между производством и качеством (ОТК, СМК и иже с ними). Ребята с производства почти всегда говорят одно и то же: качество — это забота ОТК.
Чем занимается ОТК? Контролем продукта, т.е. готового изделия. Измеряют его, анализы проводят, испытания, и т.д., по результатам которых принимают решение — выпускать (точнее, пропускать) продукт или нет. Если нет — то или в отстойник, или на переделку.
Что происходит на холиваре, когда обнаружен брак? Логика говорит: отлично, ура, мы обнаружили брак, не пропустили его дальше, надо что-то сделать с процессом производства, чтобы ситуация не повторилась. Брак ведь не случайно возник? Где-то есть проблемы — с материалами, оборудованием и его настройкой, рабочими, технологией, конструкцией и т.д. Надо разбираться, искать причины, думать всем вместе. Так ведь, производственники?
А те что в ответ? Да-да, конечно, мы разберемся, найдем, устраним, все будет хорошо. Вы только брак пропустите дальше, а то у нас план горит. Оформляется соответствующая бумажка, наличие которой вполне одобряет ISO 9001, вроде «акта приема продукции с отклонениями», корректируется для нее рынок сбыта или применение, вроде «хорошему клиенту не отгружать». Это еще неплохой вариант развития событий, бывает ведь просто указание сверху — «ОТК, не мешайте людям работать».
Продукт — конкретный, железку то есть — скорректировали, обеспечили качество, все молодцы, план, премия, корпоратив. А процесс остался на месте.
Возиться с процессом — очень муторно. Это долгая, нудная, неблагодарная работа. Исправить продукт — намного проще. Это понятная, короткая по длительности, легко измеряемая работа.
Но выход, или выхлоп от управления качеством продукта почти всегда один — качество одного, конкретного продукта. Релиза ПП, автомобиля, письменного стола, моста и т.д. Помните, как в Трансформерах было? «Ленни, тащи молоток, тут надо кое-что подправить».
А процесс работает дальше, и продолжает генерировать новые единицы продуктов. И опять ОТК найдет брак. И опять производство пообещает больше брака не допускать. И опять все поверят.
Границы продукта и процесса
В реальном производстве определить границы продукта и процесса не очень сложно. Вот колбаса, вот все остальное.
А как быть, например, в более близком нам примере — работе информационной системы? Я прошу прощения, но пример будет про 1С.
Возьмем простой, легко измеримый пример — расчет себестоимости в УПП (кто не знает — это такая программа для управления производственным предприятием, и там есть расчет себестоимости — такая длительная процедура). Возьмем не методический аспект (как что закрылось), а чисто технический — проведение документа «Расчет себестоимости». Определим два показателя качества: провелся или нет, и сколько времени проводился.
Первый показатель не всегда актуален, но и такое бывает — вот не проводится, и все. То памяти ему не хватит, то из-за блокировок упадет, то сервер 1С зависнет. Измеряется показателем типа «Булево» — да или нет, провелся или упал. В терминах управления качеством этот показатель называется «альтернативный».
Второй показатель проще и понятнее — время проведения, измеряется в секундах. В терминах управления качеством такой показатель называется «количественный».
Допустим, для заказчика технические параметры расчета себестоимости важны. Встречали, наверное, такую картину? Некоторые считают себестоимость по ночам, некоторые — в отдельной базе, некоторые пишут слезные посты на партнерской конференции — помогите, не считается, падает.
Где здесь процесс, а где продукт? Самый простой случай — когда расчет себестоимости не проводится вообще, и вас просят сделать так, чтобы он провелся, хоть как-нибудь. Это означает, что вас просят выпустить продукт, потому что текущий процесс на это не способен вообще — выход годного продукта равен нулю, сплошной брак.
Но выпустить такой продукт вручную невозможно — вам, в любом случае, придется изменить процесс. Только не на постоянной основе, а временно, чтобы продукт хоть какой-то получился. Вариантов, как это сделать, достаточно много.
Например, надо обеспечить отсутствие блокировок на время проведения. Самое простое — выгнать всех пользователей из базы, или работать в только что снятой копии (а потом перенести в рабочую документ со всеми движениями). Еще вариант — проводить вне транзакции. Разумеется, надо поставить границу запрета (если ее не было) — это тоже снизит вероятность блокировок.
Потом надо сделать так, чтобы сервер 1С не падал. В первую очередь, снять ограничения по памяти на rphost — бывает, что там поставят 1–1.5 Гб, а расчет себестоимости хочет больше, и процесс, на котором он висит, падает. Поэкспериментировать, подобрать подходящее значение можно потом, сейчас от вас требуется продукт, поэтому просто снимаем ограничение. Пользователей же нет в базе уже.
Дальше надо убрать отрицательные остатки в регистрах (если расчет идет на РАУЗ). Обучать бухгалтеров тому, как это делать, объяснять им влияние отрицательных остатков на скорость расчета просто некогда — надо продукт выпустить. Что делать, садимся и исправляем вручную, хотя бы самые вопиющие минусы. Заодно проверяем, чтобы не было миллиардов в суммах — для этого придется некоторые первичные документы перепровести.
Так, что еще? А, да — надо убрать зацикленность в переделах. Многие бухгалтера любят комплектациями выпускать продукцию саму из себя, да не по разу. Для расчета себестоимости это — зло, потому что многократно растет число узлов.
Надо бы, конечно, объяснить им, что так делать нельзя, что надо искать нормальное методическое решение, а не лишь бы проводки сформировались. Но когда это делать? Не сейчас же, правильно? Надо расчет себестоимости провести. Продукт выпустить.
Ладно, переделываем быстренько комплектации — меняем вид операции с «Комплектация номенклатуры» на «Выпуск продукции», так расчет себестоимости их легче проглатывает.
На всякий случай еще ставим сервер под платформой 8.2 — она постабильнее работает на больших операциях.
Пробуем — о, провелся! Очень долго крутился, но все-таки — получилось! Добьем еще немного, чтобы вау-эффект был сильнее.
Видим, что слишком много записей в регистре учета затрат — это плохо. Так, что там с косвенными? Ну конечно, как всегда — распределяется «все на все», отсюда и огромное количество записей. Берем за шкирку главбуха и пробуем выяснить, что там в учетной политике сказано про распределение косвенных. Куда какие затраты должны распределяться? Вот зарплата АУП цеха № 1 почему падает на весь выпуск всех цехов? А 25-й счет цеха № 2 почему в себестоимости цеха № 3? Главбух, отвечай, как должно-то быть?
Главбух, как положено, говорит: должно быть так, чтобы закрылось. Продукт надо выпустить. Опустел 25 счет — и слава Богу. Какая структура затрат? Да кто ее смотрит по данным бух.учета? Все равно экономисты в экселе потом структуру затрат свою клепают, по данным первички, а не по результатам закрытия.
Ну как, может, совещание собрать? Объяснить им, что не используют все возможности системы, что вместо учета у них — котел? Что в бумажной учетной политике у них — одно, а на деле — другое? Нет, конечно, не до этого. Надо срочно продукт требуемого качества выпустить — чтобы расчет себестоимости провелся, хотя бы, минут за 15.
Ладно, быстренько договариваемся с главбухом об изменении способов распределения затрат — редактируем схемы компоновки так, чтобы косвенные затраты производственных подразделений закрывались «на себя», т.е. только на свой выпуск. Делаем более точным распределение затрат непроизводственных подразделений. И вуаля — записей в регистре учета затрат стало вдвое меньше. Расчет себестоимости проводится за 15 минут.
Продукт выпущен, его качество соответствует требованиям потребителя.
Обратная связь
Вы, возможно, подумали, что так делать не стоит — ну, как я написал выше, упираться и продукт выпускать.
А классика управления качеством говорит: отлично, молодец, красава! Теперь, поработав над продуктом, ты знаешь, что не так с процессом! Давай, беги на вход процесса, и вноси изменения!
Это — петля обратной связи, одна из ключевых моделей в управлении качеством. На ней основано всем известное «непрерывное улучшение». Увидел проблему в продукте, нашел ее причину в процессе, исправил, посмотрел на результат. И так — до бесконечности.
Зачем бежать на вход процесса? Ну, вроде, понятно — чтобы следующий расчет себестоимости тоже случился, и занял те же 15 минут. Что вы будете делать — зависит от контекста.
Если вы — «призванный» аутсорсер, то ограничитесь рекомендациями, подпишете акт и уйдете. А может, и рекомендаций не дадите — останетесь уникальным спасителем продукта.
Если вы — местный, фикси, то, с высокой вероятностью, тоже «уйдете» — обратно за свой компьютер. Причем, с точки зрения карьеры заводского программиста, это будет лучшим решением. Вы ведь уходите победителем, как Зидан из Реала.
Если же скажете «э, не, так дело не пойдет, давайте учет налаживать», то очень быстро превратитесь из победителя в проигравшего — мерзкого зануду, который вечно ноет о том, как все неправильно работают.
В описанном примере петля обратной связи обычно очень короткая, и никакая она не петля — совещание с разбором ошибок и их причин и план мероприятий по устранению. Ну и обещания от всех участвующих служб «начать с понедельника новую жизнь». Реализовывать план уже не нужно, потому что второго совещания не будет. Ровно так же, как на холиварах производства и ОТК.
Хотя, если разобраться, у вас на руках готовый список улучшений процесса.
Немного пошаманите с настройками сервера, найдете баланс производительности и ограничений, чтобы обеспечить комфортную работу пользователей и проведение расчета себестоимости.
Сформулируете несколько правил оформления первички, чтобы избегать зацикливания переделов, оформите их в виде инструкций и автоматизируете контроль, чтобы никто не ошибался, намеренно или случайно.
Приведете-таки настройки распределения затрат в соответствие с учетной политикой, чтобы целью было не «чтобы закрылось», а «получение адекватной оценки себестоимости выпуска, по структуре и суммам».
Создадите простой инструмент контроля наличия отрицательных остатков, и вмените его использование в обязанности бухгалтерии. Заодно воспользуетесь возможностью, которая есть в 1С — фоновый пересчет себестоимости по регл.заданию, чтобы видеть проблемы каждый день, и работать с ними каждый день, а не при закрытии квартала.
Вроде просто, да? Все ведь известно и понятно, никакой магии. Но будете ли вы это делать? Да нет, конечно. А почему?
Это никому не надо — таков ведь ответ? Можно, конечно, спорить, но в реальности так и есть.
Внимание руководства
Как ни странно, но главная проблема управления качеством — внимание руководства, а точнее — его отсутствие. Об этом и в стандартах ISO 9001 написано, и аудиторы постоянно говорят, и СМК зачастую — самый зачуханный отдел.
Внимание руководства не к качеству продукта, а к качеству процесса. В том числе процесса управления. Но руководство не хочет заниматься процессами, производящими продукт — только самими продуктами.
Вас ведь позвали в тот момент, когда не получалось выпустить продукт, или он был вопиюще плохого качества. Плохой, особенно из рук вон плохой продукт — это сигнал, на который руководство реагирует. И акцент делает — исправить продукт. Наведение порядка в процессе идет прицепом, и только после того, как исправлен продукт. Особенно, если это не внутренний, а внешний продукт — тот, что отгружается клиентам. Если его нет, или он сильно низкого качества, его просто не купят –, а это уже реальная, понятная и очевидная проблема.
Если поговорить с работниками служб менеджмента качества — откровенно, не на языке лозунгов и стандартов — то они скажут то же самое: руководству наплевать на качество. На брак — не наплевать, потому что это потери. На процесс, его корректировку и улучшение — глубоко пофиг. Не на словах, конечно, а на деле. Будь то франчайзи 1С, автозавод, производство пакетов или птицефабрика.
Последствия такого подхода, на мой личный взгляд, просто ужасающие. Как думаете, в чем они? В том, что предприятия работают не эффективно? Или в том, что куча усилий тратится на исправление продуктов, а не на создание процесса, который исключит брак?
Нет, проблема не в этом. В предыдущем материале я сказал: не знаю ни одной другой профессии, в которой трудилось бы такое же количество людей, ничего не понимающих в своем деле. Да, прошу прощения, если кого обидел — такой цели не было. Но пока останусь при своем мнении. И теперь вроде понятнее, почему никто не умеет управлять качеством.
Потому что умение управлять качеством атрофируется. Человек ведь не может уметь то, чего он не делает? А не делает, потому что задачи такой нет. Если же, каким-то чудом, задача возникает, то решать ее некому, и задачу приходится хоронить.
Отсутствие внимания руководства становится шикарной отмазкой для менеджеров качества — никому не надо, вот мы и не делаем.
Остается лишь суррогатное управление качеством, разрывающее петлю обратной связи, от продукта к входу процесса. Суррогатное управление качеством — это внедрение стандартов.
Знаем, что с качеством проблемы. Смутно понимаем, что виноват процесс. Построить логическую цепочку от следствия к причине не можем, или не хотим, или не дают, не важно. Результат-то один — не будем. И что тогда делать? Внедрить какое-нибудь готовое решение!
За примерами далеко ходить не надо. В управлении качеством набор стандартный — ISO, 5S, 6 sigma, Lean (бережливое производство). Бери стандарт, делай, что там написано, и будет тебе счастье. А оно будет? У вашей компании есть сертификат ISO? Счастье наступило?
Или внедрение информационных систем, типа ERP. Чем не таблетка? Решает оно какие-нибудь проблемы? Или только новые создает? Вам нужен ТОС. Вам нужен Scrum. Вам нужны KPI. Вам нужна белковая диета. Вам нужно бегать по утрам. Вам нужно пиво Клинское.
Не важно, что именно. Внедряется не то, что улучшит процессы, а то, что наверное улучшит процессы. Невзирая на фактические показатели, причины и следствия. Просто вслепую лупим по процессам, как из пушки по воробьям, и бежим смотреть на результат. Нет результата? Ну, наверное, рукожопые из нас артиллеристы менеджеры качества.
Вообще, попытки хоть что-то изменить, даже вслепую — это уже неплохо. Точно не знаем, что надо сделать, но делаем хоть что-нибудь. Некоторые ведь вообще ничего не меняют в системе.
Если несколько раз вслепую бабахнуть, то, может, и стрелять научимся? А, нет, там ведь тоже обратная связь нужна — поглядеть в бинокль, куда попал, и скорректировать прицел. Так что, увы.
Резюме
Принципиально можно управлять: качеством продукта, качеством процесса, требованиями потребителя.
Управление качеством продукта — это воздействие на конкретную единицу выпускаемой продукции или услуги. Остальные единицы продукта остаются без изменений, равно как и процесс их производства.
Управление качеством процесса — это воздействие на систему, производящую продукты, с целью повышения качества всех единиц продуктов.
Информация о качестве продукта может и должна быть использована для корректировки процесса.
Управлять качеством продукта следует лишь в крайнем случае, когда результат нужен срочно.
Собственно, «управление качеством» — это управление качеством процесса. Так задумано изначально.
Внимание к продуктам и их качеству смещает акцент управления, с входов и внутренностей процесса на его выход — продукт. В результате процесс живет своей жизнью, как придется.
Если кто-то говорит, что управляет качеством, но не вносит изменений в процесс — есть вероятность, что он… ну это… неправду говорит.
