Часть 1. «Цифровая пена» всё сильнее затягивает
С одной стороны за несколько сотен лет принципиально не изменилась логика производства продукта: оборудование и рабочие на основании технологических карт/рецептур перерабатывают сырье и материалы в полуфабрикаты и готовую продукцию, передавая результат своей работы дальше по участкам до склада готовой продукции для отгрузки покупателям, при этом собственники ожидают максимальной отдачи от инвестиций.
С другой стороны, начиная с 30-х годов прошлого века, изменения в производственных системах, развитие компьютеров и аналитики, а также миллиарды долларов, вброшенные в консалтинг, породили вокруг бесконечное количество информации, моделей, систем, программных продуктов. Часто начинает казаться, что современные руководители, просто тонут в этой «цифровой пене», не всегда понимая, как соединить «теплое» с «белым», например, внедрение ERP, желание повысить скорость выпуска и сделать завод более рентабельным, а также развивать «мягкие навыки» (soft skills). И вокруг армия консультантов: «Вам нужно внедрить Бережливое производство», «У вас нет нормального управленческого учета», «Вам срочно нужно ERP», «Зачем тратить большие бюджеты, давайте всё сделаем в экселе» и т.д.
В России ситуация осложнилась тем, что в 90-е годы была уничтожена советская научная школа управления производством и в течение 20 лет мы утратили собственные наработки и системно не взяли чужие, за исключением лидеров отраслей. В итоге сегодня видим засилье литературы из серии «Богатый папа – бедный папа» или «Коучинг – наше всё», а также разные курсы МВА, где руководителей и собственников бизнеса учат в основном лучшим практикам финтеха и ИТ.
Выросло новое поколение планировщиков, экономистов, технологов, механиков, ИТ, которые концептуально не понимают завод как систему элементов и систему управления. И когда я в очередной раз вижу планирование выпуска в экселе, то задаю вопрос: «А Вы знаете, что эксель для Windows появился в 1987 г. и Visual Basic для приложений в него добавили в 1993 г.?» То есть прошло почти 40 лет, появились принципиально иные подходы к построению ИТ-архитектуры и создания управленческой аналитики. При этом не хочется прыгать в другую крайность – вот сейчас ИИ-агенты решат все проблемы или давайте сделаем «Цифровой двойник завода» и сразу всё полетит.
Не полетит, поскольку невозможно автоматизировать хаос, который к тому же часто в голове.
Часть 2. Как создать рельсы, по которым будем дальше ездить
Сравнение с рельсами, на мой взгляд, абсолютно уместное, так как в самом начале мы создаем последовательность рабочих центров, которые будем далее использовать для производства.
Покажем на примере производства пончиков:
Шаг 1. «Расставляем» критическое оборудование по потоку:
Шаг 2. Формируем справочник оборудования, задаем контролируемые параметры:
С точки зрения управления мы должны выделить несколько элементов:
— установленная (максимальная) мощность оборудования – показывает с какой максимальной скоростью оно может работать и какое количество единиц продукции может через себя пропускать в единицу времени (час/смена);
— основные регулируемые параметры (3-5) – их контролирует оператор/рабочий в ходе выполнения заказа; самые частотные – скорость вращения вала, температура, давление, ширина материала, сила сжатия/натяжения, длительность (например, смешивания);
— основные узлы для техобслуживания и ремонта (20-30) – чтобы позднее получать данные по частоте и длительности ремонта по ним;
— основные возможные причины простоев оборудования, кроме ремонта (30-40) – также для получения аналитики и расчета % полезного времени работы станка;
— время переналадки с заказа N1 на заказ N2 – среднее нормативное или сценарии в зависимости от типа заказа.
Далее, пример по фритюрным аппаратам
Шаг 3. Добавляем важные нормативы времени для оборудования
Шаг 4. Формируем набор КПЭ/KPI для последующего мониторинга
Важный комментарий – мы здесь не говорим про ИТ-решение, с помощью чего мы формируем справочники и нормативы. Я хочу пока остаться на уровне «чистой логики», а уже после того, как разберемся в понятиях, сможем объективно перейти к ИТ-архитектуре, поскольку здесь будет «зоопарк» ИТ-решений, особенно с учетом того, что уже есть на заводе и потрачены денежные средства на покупку лицензий и внедрение. Скорее всего, это будет комбинация из учетных систем (бухгалтерия, склад, ERP, CRM), баз данных, моделей анализа данных и систем для визуализации результатов и прогнозов. Но точно, не «давайте всё сразу сделаем на 1С:ERP».
Шаг 5. Источники получения данных
В принципе можно выделить 3 типа операций;
— автоматическая (станок по определенной программе обрабатывает деталь или полуфабрикат);
— полуавтоматическая (оператор кладет/вставляет заготовку и, как правило, что-то нажимает);
— ручная (например, удаление облоя после литья или закладка сырья в бункер/дисольвер).
Это, в свою очередь будет накладывать отпечаток на то, откуда можно брать данные для автоматической загрузки в единую базу данных:
— данные со станка автоматически передаются на сервер рядом и их можно выгружать;
— можно выгружать данные с контроллера, который установлен на оборудовании;
— можно установить датчики на вал вращения, замеры температуры и других параметров и контроллер и с него получать логи;
— можно установить датчики на операцию нажатия кнопки оператором и контроллер и с него получать логи по факту нажатия;
— можно настроить рабочее место оператора в ИТ-системе для ручного ввода данных в систему;
— можно установить специальные сканеры, которые будут «щелкать» итог операции, например, проход ряда изделий по конвейеру или сброс в контейнер;
— можно установить камеры для записи ручных операций и разработать модель на основе машинного обучения для перевода видео в нужную «цифру» (так называемое «техническое зрение», самый дорогой из предлагаемых вариантов).
Если заметили, я не предлагаю поставить замерщика с планшетом рядом, поскольку считаю эту историю худшей из возможных. Случайная выборка, интерпретация в ходе замера, последующее занесение и ручная обработка в компьютере… Вы гарантированно получаете данные для неоптимального решения; к тому же не сможете оценить эффективность принятого решения
(продолжение следует)
Источник: habr.com
