Poka-yoke. Оператор производственной линии – пользователь 1С. Кто сказал, что 1С только для финансов?

Меня зовут Макаров Дмитрий. Последние 11 лет я занимаюсь автоматизацией 1С, руковожу проектным отделом в компании «Информационные технологии». В 2012 году я впервые встретился с внедрением системы защиты от ошибок на производственном предприятии. Это направление показалось мне достаточно интересным и перспективным, и с тех пор я стараюсь развивать его в нашей компании.

Что такое Poka-yoke-система? Зачем она нужна?

Poka-yoke — японский термин, который обозначает один из инструментов бережливого производства, это методы и приспособления, которые помогают избежать ошибок в процессе производства, либо вовремя выявить ошибки, чтобы дефектные изделия не поступили в следующий этап производства. Я предлагаю рассмотреть концепцию, в которой ввод данных в систему происходит автоматизировано и в процессе выполнения хозяйственной операции. Например, когда кладовщик собирает компоненты для передачи в производственный цех или в момент выполнения производственной операции. Произвели тех. операцию №1 – система должна о ней узнать. Произвели тех. операцию №2 – система так же должна о ней узнать, выполнить необходимые проверки и принять решение о том, можно ли передавать полуфабрикат далее по производственной цепочке или нет. Тем самым защитив конечное изделие от брака.

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

Основной ответ на вопрос «Зачем внедрять систему Poka-yoke?» – с помощью этой системы можно организовать работу оператора сборочной линии или кладовщика таким образом, как будто они обладают знаниями инженера по качеству или технолога. 

Также при внедрении подобных систем есть еще пара приятных моментов, которые могут хорошо отразиться на работе предприятия. 

• Во-первых, это – расчет реального времени выполнения операций. Понятно, что технологи знают, сколько производиться та или иная технологическая операция, но эти знания могут со временем устаревать – они когда-то посчитали и уже полгода/год пользуются этим временем производства. Система контроля хода производства и система защиты от ошибок позволят получать эту информацию в режиме реального времени. Например, как могут повлиять на время производства какие-то изменения в технологии? Как может повлиять на время производства изменение каких-то характеристик готовой продукции? Насколько эффективно работает та или иная смена, тот или иной человек? Укладываются ли они в какие-то общие регламенты? Это – дополнительный хороший механизм для технологов.

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

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

В качестве примера на слайде представлен отчет, который показывает историю сборки заказа. По фамилии мы знаем, кто производил, кто был контролером ОТК на этом заказе, кто допустил его на склад готовой продукции и т.д.

Запуск Poka-yoke

Запуск Poka-yoke-системы немного отличается от запуска классических систем учета, потому что эта система должна обладать некоторыми особыми свойствами: 

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

• Система Poka-yoke должна обладать повышенной отказоустойчивостью – без этого мы не сможем работать в режиме реального времени. 

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

Как избежать проблем

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

Первое – не пытаться охватить весь процесс от склада сырья до склада готовой продукции. «Слона нужно кушать по частям». Мы должны построить процесс запуска системы по этапам: сначала автоматизируем склад сырья, потом переходим к автоматизации первого производственного участка, далее второго, третьего – и т.д. И по ходу превращения сырья в готовую продукцию мы также должны двигаться поэтапно: как только запустили и отладили первый этап, переходить к последующему и т.д.

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

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

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

Третье, что делает нашу систему именно Poka-yoke системой – это то, что работать в системе неправильно должно быть невозможно или неудобно, а работать верно – легко и комфортно. 

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

Следующее качество, которым должна обладать Poka-yoke-система – это железобетонная логика. Имеется в виду, что логику нужно выстроить таким образом, чтобы она максимально отражала то, что происходит в производственном цеху. Нужно задавать как можно больше вопросов: «А что, если?»

• А что, если мы здесь допустили брак? Куда этот полуфабрикат пойдет – на склад изолятора или он будет возвращен на доработку?

• А сколько раз полуфабрикат может вернуться на доработку?

• А что, если определенный рабочий центр в цепочке у нас выходит из строя? Мы можем продолжать работать или нам нужно остановить работу? 

Мы должны задавать множество вопросов «А что, если?», и в нашей программе это должно найти отражение. Потому что мы с вами все внедряли регламентированную «1С:Бухгалтерию», и даже там мы встречали кучу нюансов, которые нужно отразить. А производственную систему каждый завод регламентирует сам для себя, и нюансов там будет очень много.

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

Следующее – это плавный пуск. 

Имеется в виду, что наша система должна контролировать некие технологические параметры производства, либо какие-то еще регламенты. Если мы запустим сразу все, то большая вероятность того, что система не заработает. 

• Например, мы говорим кладовщику: «С завтрашнего дня все, что к вам приходит на склад сырья, вы должны маркировать и размещать на складе». При запуске этого процесса, возможно, будут какие-то нюансы, которые требуют отладки – мы их отладим. 

• Далее говорим: «Теперь при выдаче этих комплектующих в цех нужно считывать сканером маркировку». Опять – запустили, отладили, работает.

• Далее начинаем потихоньку «затягивать тиски», говорим кладовщику: «Есть заявка в производство, нужно выдавать детали в цех только согласно этой заявке. А если какой-то номенклатуры в заявке нет, а вы пытаетесь ее выдать, система ее не пропустит. Даже если вы эту деталь все-таки отдадите в цех, то он потом вернет вам ее обратно, и ваши грузчики будут бегать туда-сюда». Запустили, отладили, и переходим к следующему контролирующему параметру.

Так мы должны постепенно включать каждый контролирующий параметр, чтобы наши пользователи не захлебнулись в потоке новой информации и новых действий. Потому что нюансов будет много, нужно найти отражение в системе этих нюансов. И если они будут натыкаться – то на одну проблему, то на другую, то на третью, они это бросят и начнут заниматься тем, чем они занимаются лучше всего – будут производить продукцию. Поэтому необходимо плавное «сжимание тисков», чтобы в итоге пользователь работал именно в том регламенте, который требуется. Потому что иначе все эти регламенты соблюдаются «постольку-поскольку».

Следующее – это тестирование оборудования. Понятно, что Poka-yoke-система – это программно-аппаратный комплекс с большим количеством оборудования. Все нюансы, которые Вы не заметите, проектируя систему, можно обнаружить в процессе тестирования оборудования. Практически любой дистрибьютер оборудование может предоставить оборудование для тестов, с последующим выкупом если все устраивает. Возьмите терминал сбора данных и организуйте точку доступа Wi-Fi, проверьте качество связи в том помещении, где будет использоваться устройство и с тем оборудованием, которое будет использоваться в проекте. Необходимо проверить качество считывания штрих кода, распечатанного на принтере этикеток, размер этикетки, помещается ли туда этот ШК.   Могут быть особенности конкретного аппарата, могут быть особенности конкретного помещения. Сделайте монтажную схему оборудования, возможно где-то придется тянуть электричество или сетевой кабель. Возможно придется организовать несколько точек доступа. А возможно и вообще не получиться организовать беспроводную сеть, например, если в помещении есть сварочный пост. Когда будут подписаны договора и закуплено оборудование собирать проект придется из того что есть. 

Аппаратная часть

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

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

Терминалы сбора данных, могут работать в двух режимах:

Off-Line – использовать подобные терминалы имеет смысл только в том случае если обмен данными односторонний и организован по принципу из ТСД в 1С. И нет необходимости в оперативном получении данных от ТСД. Для разработки подобных приложений можно использовать MobileLogistics, Mobile SMARTS.

On-line – Могут решать любые задачи. Вариант организации подобной схемы возможен через RDP, но тут необходима качественная связь, так как при подвисании RDP пользователь видит картинку и слышит пиканье сканера, если не обратит внимание на экран, то создается иллюзия что все работает прекрасно.  Очень понравилось мобильный клиент на 1С под мобильные устройства. Он дает прямое подключение к информационной базе, позволяет реализовывать на мобильном устройстве более сложную логику не же ли MobileLogistics или Mobile SMARTS, а также использовать фишки мобильного устройства (геопозиционирование, сохранение фотографий сразу в базу данных и т.д.).

Еще хочу рассказать про программируемые контроллеры. Что это такое? Это – некая плата, которую мы можем запрограммировать. Их есть несколько видов, достаточно большое количество – это Arduino, Iskra, Rapsberry. У каждой из них свой язык программирования. В интернете большое количество примеров, как с этим работать – какие-то библиотеки. 

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

С помощью программируемого контроллера мы можем собрать информацию с датчика и передать ее в 1С. К нему можно также подключить сетевую плату, WiFi – большое количество устройств. Сильно глубоко во все это вникать не нужно – достаточно базовых знаний электроники и программирования. «На коленках» можно собрать практически любое устройство, поместить его в производственном цеху, и оно будет у вас отрабатывать, собирать информацию и передавать ее в 1С, где эта информация будет анализироваться. Таким образом мы сформируем онлайн-контроль хода производства.

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

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

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

Выводы

Хочу привести пример из жизни. На производственном предприятии были возвраты – периодически возвращалась продукция по рекламациям. Это происходило достаточно редко, возврат был не валовый – все было в пределах нормы, никто на это особо не обращал внимания. Но производственный диспетчер решил проверить, в чем дело – он внес серийные номера всех возвращенных изделий и, как оказалось, что 80% изделий (у них был один и тот же брак) производились на одном и том же рабочем месте одним и тем же человеком. То есть, меняются бригады, переходят смены, люди в разные моменты работают на разных производственных центрах, но как только определенный человек попадал на определенный рабочий центр, он допускал брак. И если бы мы не ввели подобный учет, отследить это было бы просто нереально. Человека нашли, обучили, брака стало меньше.

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2018 EDUCATION.