Организация производства по Теории ограничений «с нуля». Часть 3
Программа управления производством для завода «ЗаряД». Продолжение цикла статей.
Как вы помните, создание производства началось с формулирования предложения рынку для разных целевых аудиторий, чтобы получить конкурентное преимущество уже на самом старте. Такое предложение (предложение ценности) диктовало суровые требования к производству.
А именно:
- маленькие партии производственных заказов;
- производство «на заказ» в кратчайшие сроки;
- производство больших партий «на заказ», если потребуется;
- обеспечение постоянного наличия на складе готовой продукции.
Эти требования были расписаны в минимально необходимый список функций. На первом этапе этот список состоял из 65 пунктов. Укрупненно их можно представить так:
- Программа должна обеспечивать ввод и сохранение первичной информации – движение клюшек по этапам в производстве (по партиям и по отдельности).
- Сохранять результаты испытаний (на пунктах ОТК между этапами обработки).
- Формировать большой перечень отчетов по введенным данным.
- Управлять целевыми уровнями запасов на разных складах.
- Хранить технологическую информацию по каждому SKU.
- Обеспечивать передачу и списание материалов внутри производства.
- Управлять приоритетами производственных МТО и МТА заказов.
- Автоматически обрабатывать заказы клиентов с сайта.
- Формировать задания каждой бригаде исходя из текущих приоритетов, будь то заготовительное производство или участок этикетирования.
- Рассчитывать реальные сроки производства того или иного SKU.
- Обеспечивать контроль над незавершенным производством и максимально использовать ограничение.
При нескольких сотнях SKU продукции и материалов, уследить за всеми было бы сложно. При этом остаются задачи сбора статистики, внесения изменений в технологию, адаптация буферов запасов под спрос и др. Грубое моделирование ситуации сразу показало несостоятельность идеи ручного управления. Приблизительные расчеты показали, что для выполнения этих задач понадобилось бы не менее трех работников.
Кроме формулирования требований и функций программного обеспечения, необходимо было найти способ идентификации каждой клюшки в процессе производства и эксплуатации. Мы посчитали это необходимым условием для управления, а также обеспечения высокого качества продукции. Задача оказалась непростой. Необходимо подобрать не только материал маркировки, но и способ крепления. За время производства каждая клюшка проходит ряд термических и механических обработок, ее красят, шлифуют, часть рукояти отпиливают.
Мы впервые столкнулись с подобной задачей. Оказалось, что информации по ней удивительно мало. Никто из специалистов по продажам соответствующих поставщиков не мог сказать, например, какую температуру выдерживает та или иная этикетка. Пришлось проверять самим. Рассматривались разные варианты – пластиковые пломбы, этикетки из разных материалов (бумага, полипропилен, чековая бумага и другие). Одни из них не выдерживали нагрева до 150 градусов, другие – механической обработки, третьи были сложны для нанесения маркировки.
Рассматривали даже экзотические варианты, такие как RFID. Метки RFID, которые смогли бы выдержать наши условия, большие, тяжелые (по сравнению с массой клюшки) и дорогие. Кроме этого, оборудование для их считывания стоит дорого.
Оптимальным вариантом для маркировки внутри производства признали бумажные самоклеящиеся этикетки и термотрансферный способ печати штрихкодов на них. Они легко выдерживали высокие температуры, без ущерба для считывания штрихкода переносили процесс прессования. Сканеры штрихкодов считывали показания с них, даже если этикетки были запаянными в смолу в процессе прессования.
Вопрос низкой механической устойчивости бумажных этикеток решили за счет дублирования. На пункте ОТК перед механической обработкой идентификационный номер печатался повторно и далее сопровождал клюшку уже на транспортировочном колышке до этикетирования, где на клюшку приклеивалась «чистовая» этикетка. «Чистовая» этикетка, с которой клюшка отправляется потребителям, изготавливается на полипропиленовой основе и наклеивается до финишного покрытия слоем лака.
На каждой этикетке с помощью стандартных термотрансферных принтеров печатается штрихкод (серийные номера клюшек) для идентификации в программе управления производством и 1с, а также основная дублирующая информация для визуального считывания персоналом без использования терминалов. Штрих-код считывается сканером за секунду, например при прохождении ОТК, как в супермаркете.
Подбор способа реализации
После формулировки основных требований к этому ПО мы начали подбирать готовые варианты. Результат скрупулезного исследования рынка готового ПО показал неутешительные результаты. При других требованиях и условиях результат мог бы быть и иным.
Существующие варианты готового ПО, даже заявляющие о поддержке методов Теории ограничений, по факту оказались не подходящими. Некоторые варианты могли быть адаптированы, но адаптация под наши требования стоила бы дороже, чем сама программа в несколько раз. Эти программы выступали как высокоуровневые языки программирования, на котором пишется совершенно новая программа.
Такой вариант ни нас, ни клиента не устроил. Мало того, что внедрение обходилось очень дорого, так и обслуживание, и развитие редкой узкоспециализированной платформы обойдется дорого. Было принято решение реализовывать проект с нуля на основе такой современной web-технологии, как облачный сервис, который будет работать через браузер. Основа – один из популярных php-фреймворков и база данных mySQL.
Для ускорения разработки и чтобы «не изобретать велосипед», мы решили использовать одну из конфигураций 1С для оформления заказов, документов, формирования отчетности, в том числе и бухгалтерской. В целом, этот программно-аппаратный комплекс состоит из следующих основных частей:
Основные части системы
- Система управления производством – хранит историю каждой клюшки, технологическую информацию, необходимую для производства, рассчитывает приоритеты производственных заказов, отслеживает незавершенное производство, формирует отчетность.
- Система управления дистрибуцией – управляет целевыми уровнями запасов готовой продукции на складе завода и в сети дистрибуции, формирует заявки на пополнение точек продаж и склада готовой продукции из производства.
- Система управления закупом – управляет целевыми уровнями запасов материалов и сырья, формирует заявки на пополнение.
- Интернет-магазин – через интернет-магазин принимаются заказы и оплаты на сайте ЗАРЯД.РФ. Заказы могут быть как на серийные клюшки, так и на индивидуальные, с надписью, например. Доступный для продажи ассортимент корректируется автоматически.
Преимущества такого решения
- Точное соответствие требованиям – функционал разрабатывался точно под задачу и выполнял ее оптимальным способам без лишних функций и элементов.
- Скорость работы – практически мгновенная, ощутимой разницы с десктопным решением нет.
- Стоимость обслуживания и разработки – стоимость решения значительно дешевле, чем альтернативные варианты. Специалистов по PHP на рынке значительно больше, чем, например, программистов 1С, не говоря о более экзотических технологиях. Стоимость внедрения оказалась как минимум вдвое ниже ближайшего конкурентного предложения.
- Скорость разработки – такие технологии мы очень хорошо знали за годы работы на рынке интернет-маркетинга – создавали web-проекты разной сложности. Хоть мы и разрабатывали проект с нуля, срок разработки оказался ниже, чем нам предлагали «внедренцы» другого ПО.
- Гибкость – такая реализация полностью «развязала нам руки», нет ограничений платформы, мы можем внедрять любые функции, при этом делать это постепенно – по мере необходимости. Планов по развитию этой программы много.
Не обошлось и без сложностей. Например, много усилий было потрачено на интеграцию принтеров штрих-кодов. Их особенность в том, что хоть внешне они и выглядят как обычные принтеры, напрямую из браузера на них печатать нельзя. Адаптация специальной программы, которая преобразовывала сигналы в понятные им, решила проблему.
После выбора архитектуры решения и способов взаимодействия возник вопрос размещения аппаратуры. Основные рабочие терминалы состоят из следующих частей: компьютер, сканер штрих-кодов, принтер штрих-кодов, клавиатура, мышь. Оборудование должно размещаться в цеху, поэтому вопрос физической защиты оборудования возник сразу.
Вариантов было немного. Самым «правильным» представлялся вариант создания терминалов на манер таких, которые стоят в магазинах и других общественных местах. Сенсорный монитор в таком варианте служил одновременно и клавиатурой и мышью. На начальном этапе работы над проектом для тестирования были приобретены один экземпляр подобного терминала, а также другое оборудование для обустройства полноценного будущего рабочего места. На нем проводили отладку работы оборудования и программы, а также дорабатывали интерфейсы для повышения удобства работы.
Разработка программы и ввод ее в эксплуатацию проводились в несколько этапов. Сначала разрабатывался основной функционал, обеспечивающий основные процессы в производстве, затем остальные функции, например, отчеты. На первом этапе многие функции были просто не нужны, и разрабатывать их было даже вредно – все равно пришлось бы переделывать. Многие процессы внутри производства за время запуска значительно изменились по сравнению с теми, под которые проектировалась программа. В основном, участки с высокой неопределенностью были известны заранее, и мы были к этому готовы. Поэтому нам не переделок было немного, и нужный функционал создавался, когда возникала необходимость в нем.
Проектирование и разработка модели были выполнены за 1 месяц. На наш взгляд, модель – обязательный этап в проектировании сложных систем. Наличие модели позволяет показать имитацию работы будущей программы и оценить работоспособность и удобство предлагаемых интерфейсов еще задолго до их разработки. Кроме того, она позволяет заказчику и исполнителю разговаривать на одном языке. Немаловажно и то, что стоимость внесения изменений на этом этапе в десятки раз дешевле, чем на этапе уже работающего продукта.
Разработка функционала для начала производства заняла 4 месяца, и еще 2 месяца мы адаптировали функционал под изменения, устраняли недочеты и ошибки, а также доделывали второстепенные функции уже в процессе работы производства.
Обучение персонала
В процессе разработки, незадолго перед запуском завода, мы провели двухдневное обучение персонала подходу теории ограничений к управлению производством – теоретическим основам того, как будет строиться управление. Это помогло сотрудникам понять, как необходимо действовать в тех или иных ситуациях, и почему программа предлагает сделать именно так, а не иначе.
Кроме обучения, провели первую презентацию программы для управления производством. К тому времени программа была еще не готова, но мы показали модель будущей программы, как она будет выглядеть и работать, схему движения данных.
В процессе обсуждения после демонстрации модели все вместе нашли решение важной задачи. Результатом явилось создание той цепочки процессов, которые сейчас позволяют производить клюшки с индивидуальными надписями по заказам с сайта всего за три дня.
Максимальное использование ограничения
Мы рассчитывали функционал программы управления под разные ситуации, например, под максимальную загрузку производства, когда мы бы столкнулись с ограничением мощности. Моделируя эту ситуацию, мы определили, что участок прессования станет узким местом, которое будет нелегко расширить. Это физическое ограничение, увеличить пропускную способность которого можно будет только за счет покупки новых прессов и пресс-форм, что весьма дорого.
По факту, за прошедшее время ограничение перемещалось много раз. Бывало, что по некоторым моделям мы наблюдали ограничение рынка, по некоторым – ограничение мощности.
В этой ситуации необходимо находить решения по максимальному использованию нашего ограничения, то есть, производить только то, что действительно необходимо в первую очередь, только в том количестве, сколько необходимо, минимизировав при этом время переналадок (в нашем случае – смена пресс-форм, их прогрев). Ну и, конечно, не допускать простоев.
Тут надо подробнее остановиться на ограничениях, накладываемых технологией, на данном участке. В одном прессе может одновременно находится 4 пресс-формы, в каждой – по 2 будущих клюшки. Каждая пресс-форма проходит 2 этапа обработки – сначала нагрев, затем постепенное охлаждение в специальном охладителе. Учитывая то, что под каждый тип клюшки существует своя пресс-форма и их количество ограничено, мы не можем производить одновременно много одинаковых клюшек.
Время обработки на каждом этапе строго регламентировано. Мы можем управлять только составом пресс-форм в каждой закладке в пресс, то есть когда делать переналадку, менять ту или иную пресс-форму при очередной загрузке в пресс. Для решения задачи, что именно прессовать сейчас, мы делим все входящие производственные заказы на виртуальные потоки по используемым пресс-формам. Количество потоков определяется количеством одновременно задействованных пресс-форм. Далее – выстраиваем все производственные заказы внутри каждого потока по приоритету, который определяет, насколько мы удовлетворяем потребности наших клиентов. Для МТА-заказов (производство для обеспечения наличия) – статус буфера запаса на складе этого полуфабриката, для МТО (производство на заказ) – дата сдачи заказа.
Для персонала это выглядит просто – программа на основе имеющейся очереди производственных заказов и того, что уже в производстве, выставляет приоритеты и темп запуска производства заготовок клюшек на участок формообразования. А также формирует задание на очередной цикл прессования из тех заготовок, которые уже готовы.
Программа обеспечивает определенный размер запаса заготовок в каждом потоке и сигнализирует, если запас в потоке становится меньше или больше оптимального. Этот запас необходим для обеспечения бесперебойной работы потока, а значит и максимального использования ограничения, если какая-то из заготовок будет опаздывать.
Процесс непрерывных улучшений
В формировании рукояти клюшки участвует по 2 «намотчицы», как их называют, каждая из которых шифруется своим номером. Они представлены по горизонтали, столбцы – намотчицы, формирующие крюк клюшки.
Знак суммы показывает, сколько такое сочетание «намотчиц» сделало совместных клюшек за выбранный срок. Ряд цифр в каждой ячейке показывает количество и типы брака в этом суммарном количестве. Например, у 16-й, 3-й и 1-й – последняя цифра (тип брака «слом в переходе») достаточно стабильно проявляется. У других такого тип брака нет, значит, первые три что-то делают не так. Это повод обратить внимание на их действия, провести наблюдение, что и как они делают, и провести корректирующее обучение.
Это только один из примеров. Анализ и корректирующие действия производятся постоянно. Это позволило снизить долю брака за 8 месяцев больше, чем в 5 раз! При этом здесь не отображен участок старта производства, когда доля брака могла быть и больше 50% от объема выпуска.
Увеличение доли брака в один из месяцев связано с переходом на новую технологию и материалы, что неизбежно ведет к увеличению брака и изъятию большого количества образцов на испытания, в том числе и разрушающие.
Сбор информации о клюшках не прекращается и после продажи. Каждый гарантийный случай возврата клюшки подробно рассматривается, и при необходимости вносятся изменения.
Другой пример – анализ значения буфера у завершенных заказов, этот отчет позволяет анализировать процессы в производстве, выявлять узкие места и непрерывно совершенствовать их. Это позволило обеспечить стабильное снижение времени производства, при том, что объем производства увеличивался.
Кроме набора специализированных отчетов, программа также формирует сводный отчет по основным метрикам производства и дистрибуции для руководителя в графическом виде.
Продолжение следует...
Автор: Андрей Конопля, консультант по Теории ограничений, специалист по внедрению ПО