Энтропия счетов: почему столкновения ревизий убивают выход продукции

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

Операторы не ошибаются при сборке; система терпит неудачу в синхронизации.

В одном распространённом сценарии механическая команда выпускает заказ на инженерное изменение (ECO) для модификации радиатора, команда упаковки выпускает отдельный ECO для новых пенопластовых вставок, а команда прошивки выпускает патч для снижения скорости вентилятора. Если эти три изменения поступают на завод без явной связи, руководитель линии внедряет их по мере утверждения. В итоге получается 2000 устройств с старым маленьким радиатором, но с новым профилем вентилятора на низкой скорости. Результат — тепловое отключение в эксплуатации, и всё из-за того, что «Дата вступления в силу» для изменения прошивки была установлена как «После утверждения», а для механического изменения — как «Израсходовать запас».

Инженерия обычно работает нормально. Трение возникает из-за того, что инженерию рассматривают как непрерывный поток, в то время как производство происходит в дискретных снимках. Если рассматривать спецификацию материалов (BOM) как репозиторий программного обеспечения, вы приглашаете хаос. Откат git ничего не стоит. Откат инструмента для литья пластика или списание 5000 печатных плат из-за несоответствия буквы ревизии трафарету — это ошибка на шесть цифр. Столкновение нескольких ECO во время запланированной сборки — самая частая причина «мягких» потерь выхода годных изделий. Вы не собрали устройство неправильно; вы просто собрали неправильное устройство из-за столкновения сроков.

Ловушка «Последней ревизии»

В современном аппаратном развитии существует опасное предположение, что «последняя» версия файла — это та, которую следует собирать. В системе управления жизненным циклом продукта (PLM) файл может быть «Утверждён» задолго до того, как он будет «Внедрён». Именно в этом разрыве исчезают деньги.

Инженер, сидящий в офисе в Остине, видит, что новый дизайн кронштейна утверждён в системе, и предполагает, что следующий собранный блок будет с ним. Но завод работает с физическими запасами, а не с цифровым статусом. Если на складе есть 4000 старых кронштейнов, логика завода по умолчанию — использовать их, чтобы избежать потерь. Если ECO явно не требует действия «Очистить и списать», «последняя» ревизия существует только на сервере, а не на линии.

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

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

Прошивка — это компонент, а не настроение

Самой частой жертвой столкновения ревизий является прошивка. Команды разработчиков программного обеспечения привыкли к непрерывной интеграции; они рассматривают код как живой, развивающийся объект. Производство же рассматривает код как деталь, ничем не отличающуюся от винта или резистора. Если бинарный файл прошивки не имеет уникального номера детали и контролируемой ревизии в BOM, он фактически не существует для оператора линии.

Рассмотрим сценарий «Фантомной прошивки». Разработчик загружает версию 2.1 в репозиторий для исправления критической ошибки. Однако заводские программисты прошивают бинарный файл, расположенный в определённой папке на тестовом сервере. Если процесс ECO явно не инструктирует тестового инженера проверить новую контрольную сумму и обновить образ программатора, завод будет бесконечно прошивать версию 2.0. Устройства пройдут функциональный тест, потому что, вероятно, тестовые лимиты также не были обновлены для проверки новой строки версии.

Здесь возникает соблазн полагаться на обновления по воздуху (OTA) для исправления таких проблем позже. Это опасная опора. OTA не может исправить устройство, которое превращается в «кирпич» сразу после загрузки, потому что версия загрузчика не совпадает с картой разделов приложения. Более того, полагаться на обновления в полевых условиях разрушает вашу способность диагностировать сбои. Если клиент обращается в поддержку с «кирпичом», а ваша команда RMA не может определить по серийному номеру, какой код был изначально прошит на заводе, они работают вслепую. Они не знают, ищут ли они аппаратный дефект или программную ошибку. Если бинарный файл не имеет номера детали, он не существует для оператора линии и уж точно не поможет вашей службе поддержки.

Матрица распределения

Самое важное поле в любом ECO — это не описание изменения, а «Распоряжение» со старым материалом. Здесь рассчитывается финансовая реальность изменения. При введении новой ревизии необходимо учитывать материал в четырёх состояниях: на складе (On Hand), в заказе (On Order), в процессе производства (WIP — Work in Process) и готовая продукция (Finished Goods), находящаяся на складе.

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

Вы должны провести расчёты. Часто дешевле списать $5 000 необработанных печатных плат, чем оплачивать три дня простоя линии, пока операторы пытаются выполнить деликатную доработку. Доработка почти всегда — это фантазия; списание — цена ясности.

Протокол чистого разрыва

Чтобы остановить убытки, необходимо обеспечить «чистый разрыв». Плавное изменение — когда новые ревизии смешиваются с старыми в одной партии — приемлемо только для деталей, которые 100% взаимозаменяемы по форме, посадке и функции, например, винт от другого поставщика. Для всего остального нужен жёсткий разрыв.

Это означает определение точки перехода не по календарной дате, которая может быть неустойчивой, а по конкретному коду партии или серийному номеру. «Ревизия B начинается с SN: 100500». Эта инструкция позволяет заводу сегрегировать линию. Они могут закончить выпуск ревизии A, очистить линию, удалить старые запасы и начать ревизию B с новой настройки.

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