📅 · 12 мин чтения · Команда Meta Smart Factory
Большинство заводов, у которых цифровизация не получилась, провалились не на технологии. Шлюз работал, и платформа делала всё, что показывали на демонстрации. Провалился порядок: аналитику купили раньше, чем появились данные; оптимизатор поставили над производственным учётом, которого никто не построил; платформу выбрали раньше, чем кто-либо сформулировал вопрос.
Порядок оказывается самой трудной частью, и именно его вендорские материалы обходят стороной, потому что честная версия означает предложить клиенту купить в этом году меньше. Эта страница посвящена такому порядку.
Большинство случаев объясняются четырьмя причинами. Все четыре являются сбоями программы, продукт здесь ни при чём, и в этом суть: именно ими завод управляет сам. Софт отказывает и по собственным причинам, и этому списку место в закупке: устройство транзакций, производительность на масштабе, вендор, участие которого заканчивается на запуске в эксплуатацию.
Первая — спонсор, под которым нет владельца. Спонсор утверждает бюджет и приходит на ежемесячную встречу; у владельца есть время в цехе, полномочия менять процесс и личный результат, привязанный к тому, будет ли завод через год работать иначе. Вторая — бизнес-кейс, предполагающий данные, которых нет: план анализировать простои упирается в колонку свободного текста в сменном рапорте. Третья — пилот, который изначально не был рассчитан на тиражирование. Четвёртая — покупка платформы до того, как известен вопрос: завод получает мощную систему без первого применения.
Первый проект должен исходить из ограничения завода, список модулей тут вторичен. На большинстве предприятий потери невзрачные: переналадки дольше норматива, материал, который невозможно найти, двухминутные остановки, о которых никто не сообщает.
Три вопроса быстро отсеивают кандидатов. Видны ли эти потери в собственном учёте завода в виде брака, сверхурочных, срочной доставки или штрафа за просрочку? Поступил бы кто-нибудь иначе в ту же смену, если бы знал ответ? Можно ли за один производственный цикл понять, сработало ли? Мерить нужно именно цикл. Три месяца дают честную проверку в серийном многономенклатурном производстве и бессмысленны в авиастроении или в фармацевтической кампании, где единицей выступает одна кампания или один заказ.
Иногда софт оказывается неправильным ответом: если ограничение физическое, никакие данные не заставят станок работать быстрее. Измерение показывает, куда уходит мощность, и обычно по его итогам заявку на капвложения приходится перенаправить. Собственное время работы станка-кандидата оказывается хуже, чем все считали, как только посчитаны короткие остановки. При этом большая часть потерянных им часов была не его: он стоял без материала сверху, был заблокирован снизу, находился в переналадке или ждал оператора, обслуживающего два поста. Станок никогда не был ограничением, и деньги нужны в другом месте.
Ловушка в определениях. До запуска доступность берётся из сменного рапорта, где короткие остановки не записывают; после запуска остановки фиксируются автоматически, и измеренный OEE падает, потому что потери, которые были всегда, наконец посчитаны. Если никто не зафиксировал старое определение и старое число, третий месяц выглядит как ухудшение, и программа тратит свой кредит доверия на самооправдание.
Поэтому выпишите текущее число и его определение целиком: какая временная база лежит в основе процента, откуда берётся идеальное время цикла, как классифицируются простои, исключается ли плановое обслуживание и как учитывается переделка. Первые два решают почти всё: календарный фонд, плановый фонд и отработанный персоналом фонд времени дают одному и тому же заводу три разные цифры из одних и тех же данных, а идеальным временем цикла считают либо паспортное, либо лучшее достигнутое, либо норматив из маршрута, заданный однажды и больше не пересматривавшийся.
Затем зафиксируйте факты, которые труднее переопределить и которые сводятся с финансами: отгруженные единицы, оплаченные часы против отработанных, строки заказов, доставленные с опозданием, кредит-ноты и сверхурочные. Труднее не значит невозможно, поэтому заморозьте определение и систему-источник для каждого из них наравне с определением OEE. Своевременность поставки требует отдельного письменного решения, потому что база даты остаётся самым переспариваемым определением на любом заводе: исходное обязательство или последняя пересмотренная дата, заказ или строка заказа, отгрузка или получение.
Подключение оборудования и мастер-данные лежат под всем остальным, аналитика лежит сверху и стоит ровно столько, сколько стоят эти слои, а зависимость от мастер-данных стабильно недооценивают. MES не может выдать в работу операцию, которой нет в маршруте, а APS не может выстроить последовательность без нормативов времени, которые кто-то измерил в этом десятилетии. Поэтому, прежде чем называть дату, посчитайте детали без маршрута, нормативы времени круглыми числами, места хранения, существующие в реальности и ни в одной системе, и продублированные спецификации.
Второй шов стоит определить в самом начале. Это интеграция с ERP, где вся сложность в договорённостях: что означает подтверждение выработки на каждой стороне и кто его проводит (цех или обратное списание), как ложатся частичные количества и разделение заказов, что происходит со сторнированием после того, как материал уже перемещён, куда относится брак против нормативной себестоимости. Каждый ответ требует решения между подразделениями, которым никогда не приходилось договариваться.
Две зависимости с длинным сроком редко попадают в техническую дорожную карту. Производственный учёт, который относит выработку, остановки и брак на конкретного оператора, в Германии и значительной части Европы считается системой, способной контролировать индивидуальную производительность, поэтому до запуска нужно соглашение, согласованное с производственным советом. Согласование занимает месяцы, поэтому начинайте его в первый год вместе с мастер-данными. Содержание короткое: хранится ли вообще идентификатор оператора, кто его видит, как долго и является ли отчётность агрегированной по замыслу.
Вторая зависимость касается регулируемого производства. В фармацевтике, производстве медицинских изделий и значительной части пищевой отрасли система, которая фиксирует или обеспечивает решение о статусе качества, попадает в зону валидации: план валидации, квалификация, журнал аудита, требования к подписям, более медленный контроль изменений в дальнейшем. Отчётность, фиксация простоев и планирование остаются вне этой границы; карантин партии, решение о её статусе и версия модели, которую использует система контроля, находятся внутри неё. Определите границу до покупки модуля, потому что валидация часто оказывается самым длинным отдельным пунктом программы.
Если дать усовершенствованному планированию вчерашнее представление о том, где находится работа, последовательность будут пересобирать вручную до начала смены, планировщик вернётся в таблицу за считаные недели, а вердикт будет: софт для планирования плохой. Он не был плохим, он был слепым.
Живые входные данные делают график выполнимым, но не исполняемым, и именно в этом зазоре живёт большая часть разочарования в APS. График на идеальных данных всё равно проигнорируют, если он оптимизирует не ту цель (минимизирует переналадки, тогда как завод оценивают по срокам); если не заданы вторичные ограничения, ведь реальную последовательность определяют оснастка, матрица навыков и общий на несколько участков персонал; или если ничего не заморожено, ведь оптимизатор, пересчитывающий непрерывно, выдаёт мастеру новый план каждый раз, когда тот в него смотрит. Договоритесь о периоде заморозки, а перепланирование пусть бурлит за его пределами.
У прогноза качества та же форма: модель, предсказывающая брак, требует брака, зафиксированного на той операции, где он возник, с причиной и контекстом процесса, от станка и инструмента до партии материала.
В обслуживании есть различие, которое при продаже проскакивают. Обнаружение аномалий по вибрации или по сигнатуре тока работает без истории отказов, но это не то же самое, что работать без данных: нужны недели данных исправного состояния, покрывающих весь рабочий диапазон, иначе система будет срабатывать на каждой переналадке, а не на повреждении, и нужны датчики, установленные и опрашиваемые под те виды отказов, которые вам важны. Даже тогда она лишь говорит, что нечто необычно, а чтобы понять, какие аномалии имели значение, нужна история заказов на ремонт с видами отказов.
Камера, показывающая на экране «годен» или «не годен», тоже ещё не изменила завод: вердикт должен привязываться к производственному заказу, партии и версии модели внутри производственного учёта и записей о качестве, поэтому визуальный контроль относится к поздним возможностям и плохо подходит как точка входа. Планированию с конечной мощностью, требованиям к графику APS и границе между CMMS и предиктивным обслуживанием посвящены отдельные материалы.
Роль ИТ здесь партнёрская. Когда программой владеет ИТ, оно оптимизирует её под интеграцию и безопасность, делает это хорошо, а затем застревает на внедрении, потому что никто в этой линии не отвечает за то, пользуется ли оператор экраном. Под владельцем стоят ключевые пользователи, по одному на участок, поимённо, с выделенными часами: они решают, что экран спрашивает и в каком порядке, и цех слушает их.
Заявленное препятствие внедрению почти всегда люди; реальным препятствием обычно оказывается устройство самой транзакции. Понаблюдайте за подтверждением выработки во время переналадки: перчатки надеты, следующий заказ ждёт. Если ввод причины остановки ничего видимо не меняет, ввод превращается в налог на смену, который платят как можно позже и обычно пачкой выдумок в конце. Если он уведомляет ремонтную службу, обновляет сменную доску или меняет очерёдность следующего заказа, он становится частью работы.
Хорошо спроектированный ввод данных конкретен: терминалы у станка, управление одной рукой в перчатке, значения по умолчанию, подтянутые из заказа, и короткий список причин под тип станка вместо таксономии, из которой реально используют несколько кодов. Когда транзакция ложится на работу, обучение достаточно короткое, чтобы провести его у станка в течение смены. Когда не ложится, никакие часы в классе это не исправят, а просьба о дополнительном обучении часто оказывается проблемой проектирования, ошибочно принятой за проблему людей.
В большинстве планов обучения упускают две вещи. Первая касается исправлений: подтвердить годное количество легко научить, а вот при сторнировании неверного или разборе подтверждения, проведённого по чужому заказу, необученный пользователь и наносит реальный ущерб. Вторая в том, что обучение не разовое событие: мастерам нужно больше, чем операторам, а новички, персонал подрядчиков и многоязычный цех приходят непрерывно.
Пилоты не тиражируются по причинам, заложенным в них самих: лучшая линия, старые станки обойдены стороной, вендор на площадке каждый день, мастер-данные вычищены вручную. Пилот, рассчитанный на тиражирование, идёт на представительной линии, включает хотя бы один неудобный актив и фиксирует часы на линию, потому что только эта удельная трудоёмкость даёт честный вход в план развёртывания.
Критерии выхода и дата решения о развёртывании согласуются до старта пилота, а заключительный отрезок проходит без вендора. В этом отрезке важно покрытие, потому что пилоты редко ломаются на обычной работе. Они ломаются на первом закрытии периода, когда цифры должны сойтись с ERP и кто-то обнаруживает брак, проведённый дважды, и на первом пуске после остановки, когда шлюзы возвращаются, а буферизованные счётчики нет. Поэтому задайте покрытие: одно закрытие периода со сверкой, вся номенклатура, которую выпускает эта линия, и одна плановая остановка с последующим пуском. На большинстве заводов это месяц или один полный цикл; двух недель мало.
Жёстче всего торгуются по лицензии, а исход решают другие строки: интеграция с ERP и со станками; железо (от шлюзов и панелей до ретрофитных датчиков); чистка мастер-данных; обучение и производственное время, которое оно съедает; и внутренние трудозатраты. Чаще всего опускают строку внутренних трудозатрат: ключевые пользователи, владелец, ИТ, техники, монтирующие шлюзы, потерянный выпуск при переходе. Если эти часы никто не посчитал, бюджет неверен, как бы хорошо ни выторговали лицензию.
Физические работы делятся на две категории, которые планируются по-разному. Кабельные трассы, порты коммутаторов и сегментация между технологической и корпоративной сетью относятся к обычной инженерии с длинными сроками поставки, и её можно вести параллельно с производством. С тем, что внутри шкафа станка, так нельзя: это работы с отключением, требующие блокировки и маркировки и плановой остановки, а на большинстве заводов ещё и при действующем запрете вскрывать шкаф под напряжением. Поэтому график подключения на деле ограничен тем, сколько остановочных окон осталось в этом году и сколько от каждого уже забрала служба обслуживания. Подключение планируется по календарю ремонтов, а не по плану внедрения софта.
Далее эксплуатационные расходы, которых не содержит ни один проектный бюджет и о которых финансовый директор спрашивает первым: стоимость в четвёртый год. Подписка или годовая поддержка продолжаются, а промышленные панели и шлюзы изнашиваются быстрее офисного железа. И главное: после ухода вендора систему ведёт кто-то внутри (поддержание мастер-данных, изменение кодов причин и маршрутов, администрирование пользователей, приём каждого релиза). Заложите отдельный бюджет на изменения в двенадцать месяцев после запуска, потому что запросы, которые стоит финансировать, приходят только тогда, когда цех начинает верить тому, что система ему показывает.
Календарь добавляет то, чего не даёт порядок зависимостей: кто решает на каждой границе и как распределяются деньги и часы. Первый год закрывает решения, дорогие в пересмотре, и закрывает их владелец вместе с финансами, ИТ и производственным советом, без перекладывания на проектную команду: определения KPI, структура мастер-данных, шов с ERP, идентификация оператора и, на регулируемом производстве, границы валидации. Внутренние трудозатраты здесь максимальны относительно расходов на лицензии, так что бюджет, устроенный как обычный ИТ-проект, уже неверен. Один пункт относится к первому году, хотя заводы его откладывают: приборный учёт крупнейших электрических нагрузок, чтобы установить базовый уровень; это именно инструментальное измерение, без моделирования, и часто он не является добровольным по требованиям энергетического стандарта или аудита.
Переход во второй год определяется суждением, по календарю его не назначить: он совершён, когда цех перестаёт игнорировать цифру системы и начинает с ней спорить. Замкнуть контур означает, что мастер или менеджер по качеству передаёт решение правилу, поэтому эти рамки согласуются с людьми, чьи полномочия сдвигаются, а расходы смещаются с внутренних часов в сторону лицензий и интеграции. Третий год оплачен двумя годами накопленной записи и получает модельный слой, а его граничным условием становится владение: у каждой возможности должен быть поимённый человек, отвечающий за порог срабатывания и график переобучения модели. Сюда же относится энергия, отнесённая на деталь, потому что для такого отнесения нужен производственный учёт, построенный за первые два года.
Два стоп-условия должны быть в решении об утверждении. Если цех не доверяет данным первого года, второй год не начинается. А перенос третьего года вперёд из-за того, что совет директоров попросил инициативу с ИИ, даёт ровно тот буксующий проект, с которого начинается эта страница.
Каждому этапу нужен рубеж с доказательством, которое можно показать скептику. После подключения: сходится ли собранный выпуск с ручным подсчётом за полную смену в пределах допуска, согласованного до проверки. После первой отчётной цифры: ведётся ли рядом старая таблица; когда её тихо перестают обновлять, цифра принята.
Один рубеж относится к первому запуску производственного учёта и его почти всегда пропускают: что линия делает, когда системы нет. Как только операторы подтверждают выработку у станка, а качество ставит партии на карантин по правилу, отказ коммутатора или интерфейса останавливает производство: завод обменял планшет с бумагой на единую точку отказа. Поэтому сначала определите и проверьте деградированный режим: что терминал буферизует локально и как долго, какой предусмотрен бумажный резерв, кто вправе разрешить работу без системы и как задним числом вводится накопленное без двойного счёта. Проверяйте отключением связи во время идущей смены, потому что именно непроверенное переключение на резерв обычно превращает запуск в производственный инцидент.
После постановки производственного учёта: можете ли вы восстановить один заказ (с остановками, браком и тем, кто его вёл, на согласованном уровне идентификации), не спрашивая человека. Перед планированием: точна ли величина незавершённого производства на начало смены. Одна тенденция важнее любого отдельного рубежа: если каждая новая линия стоит столько же, сколько предыдущая, программа построила штучные инсталляции, метода у неё нет.
Meta Smart Factory закрывает описанные слои отдельными модулями: от MES, MRP и APS до качества, обслуживания, склада, машинного зрения и интеграции с ERP. Модульность делает такую последовательность покупаемой, но первая покупка включает больше, чем модуль. Это один модуль против одного названного ограничения на одном участке плюс фундамент под ним: подключение оборудования, чистка мастер-данных, шов с ERP и согласованные определения. Этот фундамент составляет большую часть трудозатрат первого года и не значится ни в одном прайс-листе, поэтому в решении об утверждении он должен стоять отдельной строкой и не прятаться внутри лицензии.
Трудные части остаются при любом выборе платформы. Договориться, что означают цифры, вычистить мастер-данные, спроектировать транзакции, которые операторы выполняют без напоминаний, и выбрать, что перестать делать: всё это общая работа. Если вы находитесь здесь, разговор о последовательности под ваше ограничение полезнее демонстрации продукта.
Обсудить с нашими экспертами