вступ
Невеликий{0}}збір друкованої плати звучить просто на відстані.
Кількість ще невелика. Можливо, проект уже пройшов прототип. Команда припускає, що наступним кроком буде просто створити ще кілька плат, підтвердити, що все досі працює, і перейти до виробництва.
Саме звідси починається дрейфування багатьох пілотних заїздів.
Невеликий{0}}збір друкованої плати перед пілотним запуском — це не просто більший прототип. Це перший етап, де повторюваність, видимість витрат і дисципліна процесу починають мати значення одночасно. Конструкція все ще може виглядати «маленькою» на папері, але поводитися зовсім по-іншому, як тільки матеріальні припущення, час тестування, контроль переглядів і технологічність починають зближуватися.
Це справжня проблема. Питання не в тому, чи малий-блок друкованої плати є малим. Питання полягає в тому, що покупцям часто не вдається зафіксувати перед пілотним запуском - і чому саме ці невраховані деталі зазвичай збивають графік.
Що покупці часто неправильно розуміють про мало{0}}складання друкованої плати
Найпоширеніше непорозуміння просте: покупці розглядають мало{0}}об’ємне складання як прототипне складання з більшою кількістю плат.
Це не так.
Робота прототипу створена для швидкого навчання. Пілотний-орієнтований-малосерійний запуск створено, щоб показати, чи можуть дизайн і процес витримати менше імпровізації. Ця зміна змінює те, що має значення.
Прототип з п’ятьма-платами може витримати обхідні шляхи вручну, часткові рішення щодо джерела та невелике{1}}роз’яснення-інженера. Пілотна серія із 100-деталів або 200 одиниць зазвичай не може витримати ті самі речі без того, щоб витрати не з’явилися в іншому місці – під час переробки, годин випробувань, циклів затвердження або відхилення графіка.
Кількість все ще виглядає контрольованою. Припущення процесу ні.
Це перше, на що часто звертають увагу покупці.
Райони, які покупці найчастіше пропускають перед пілотним запуском
Стабільність специфікації при реальній кількості збірки
Це один із найбільших промахів.
Прототип лоту міг бути створений з доступністю на місці, преміум-купівлями невеликих-кількостей, швидкістю,-підтримуваною брокером, або альтернативними варіантами, які були неофіційно схвалені лише для того, щоб проект рухався. Це цілком розумно для десяти дощок.
Це не те саме, що сказати, що специфікація готова до пілотного запуску.
Перед пілотним-орієнтованим-складанням малого обсягу питання змінюється. Це вже не "Чи можемо ми отримати достатньо деталей, щоб побудувати перші кілька дощок?" Воно стає таким: «Чи може та сама логіка пошуку підтримувати повну кількість за тих самих припущень щодо розкладу, не перетворюючи один рядок-позицію на справжнє вузьке місце?»
Саме тут проекти починають пробуксовувати.
Серія з 200-приладів все ще може зупинитися, оскільки один мікроконтроллер, роз’єм, дисплей, пристрій живлення або механічно обмежена частина була підтверджена лише для кількості прототипів. У невеликих обсягах роботи графік часто рухається з найповільнішою невирішеною частиною, а не з найшвидшою машиною.
Ось чому перегляд збірки до кінцяПостачання компонентівлогіка має значення набагато раніше, ніж очікують багато покупців.
Тестуйте стратегію, яка все ще поводиться як логіка прототипу
Тестування прототипів часто живе на стендовому стенді. Інженер вмикає плату, перевіряє ключові вузли, запускає-вгору та вирішує, що досліджувати далі.
Це цілком підходить для кількох зразків.
Пілотні запуски виявляють там, де ця логіка перестає чітко масштабуватися.
Покупець може схвалити-малосерійну збірку, не вирішуючи, чи покладатиметься проект на повторне ручне функціональне тестування, літаючий зонд, AOI плюс функціональне покриття, простий кріплення чи більш структурований тестовий шлях. Потім приходять збірки, і справжнє питання вже не в тому, "Чи працює плата?" Це стає "Чи можемо ми перевірити цю кількість достатньо послідовно, не перетворюючи тест на нове вузьке місце?"
Саме тут невеликі збірки починають поводитися набагато більше, ніж очікувалося.
Метод тестування прототипу не є автоматично правильним методом пілотного тестування. Ручна стендова перевірка, яка добре виглядає на десяти дошках, стає ускладненням набагато раніше, ніж очікують багато команд, коли кількість дощок зростає, і кожен підрозділ потребує однакової уваги.
Видимість вартості налаштування, яка надходить надто пізно
Його легко недооцінити, тому що пробіг все одно здається малим.
Не{0}}повторювана робота не зникає лише тому, що її кількість скромна. Трафарети, програмування, перші-налаштування артикула, планування кріплення та підготовка процесу ще мають відбутися. У прототипі ці витрати легко подумки приховати, оскільки вся збірка вже оформлена як навчальна робота. Під час пілотного-орієнтованого-запуску малого об’єму та сама робота з налаштування починає значно помітніше змінювати економіку агрегату.
Помилка не в тому, що існує вартість налаштування. Помилка полягає в тому, що не вдалося виявити це досить рано.
Невеликий пілотний запуск не просто тестує дошку. Це також показує, чи команда проекту достатньо чітко продумала, що все ще має бути вручну, що зараз потребує структури та яка робота з налаштування насправді виправдана на цьому етапі.
Збірка може виглядати недорогою на стадії пропозиції та все одно стати дорогою, коли навколо неї починають накопичуватися додаткові налаштування, додаткова обробка та додаткова інтерпретація.
Проблеми з DFM, які були прийнятні для прототипу, але не для пілотного
Тут кількість перестає бути головною.
Деякі проблеми дизайну не блокують партію невеликого прототипу. Вони просто створюють переборні незручності. Під час пілотного-запуску та сама проблема стає помітною як повторне підправлення-, нестабільна продуктивність, труднощі із зондуванням, неефективність панелей або шум при складанні, який сповільнює всю партію.
Панель, яка була «достатньою для п’яти дощок», може стати вузьким місцем для переробки на 100. Тестовий доступ, який був прийнятним для запуску вручну-, може викликати розчарування після повторення на повному-лоті малого обсягу. Упаковка чи рішення про відстань можуть все ще створювати робочі плати, але більше не робочі плати, які повертаються достатньо чисто, щоб створити впевненість у процесі.
Ось чому покупці часто шкодують, що розглядають очищення DFM як щось, що може почекати до закінчення пілотного запуску.
Дизайн може бути достатньо хорошим для прототипу, але все одно не бути готовим до повторення.
Глибина документації, яка все ще здається надто прототипною{0}}
Цей добре ховається, поки фактично не почнеться збірка.
Документація прототипу часто може залишатися легшою, оскільки та сама невелика група інженерів уже знає, що плата намагається зробити. Пілотні запуски не мають такої розкоші. Примітки до складання, чіткість полярності, дані центроїда, рішення щодо панелі, затверджені альтернативи, маркери редагування та спеціальні припущення щодо обробки – все це набагато важче неправильно зрозуміти.
Якщо випущений пакет «в основному зрозумілий», цього може бути достатньо для прототипу. Для невеликого-пілотного запуску «в основному зрозуміло» — це саме те місце, де запитання в рядку, плутанина в тесті та відхилення від перегляду починають викрадати час.
Пакет збірки може бути достатньо хорошим, щоб його випустити, але все ще не бути готовим до повторення.
Змініть контроль, який залишається занадто вільним
Пілотні запуски карають слабкий контроль версій набагато швидше, ніж прототипи.
Під час ранньої роботи над прототипом команди можуть вижити завдяки швидшим змінам, частковим оновленням і роз’ясненням між-{1}}інженерами. Щойно проект переходить до-пілотної логіки низького обсягу, це розхитування починає витрачати реальний час.
Якщо ревізія специфікації, результати складання, затверджені альтернативи, базова версія мікропрограми та очікування покупців не узгоджуються, то збірка перестає бути етапом навчання та починає ставати проблемою координації.
Для пілотного запуску не потрібна повна жорсткість-масового виробництва. Він справді потребує більшого контролю, ніж більшість команд прототипів звикли нести.
Переробку припущень ніхто не оскаржував досить рано
Невелика конструкція часто надто добре приховує переробку.
На прототипі додаткова ретуш-може здаватися прийнятною, оскільки інженери все ще навчаються, а партія невелика. Перед пілотним запуском покупцям потрібно поставити складніше питання: чи ми все ще перевіряємо продукт, чи ми спокійно платимо, щоб компенсувати нестабільність процесу?
Ця різниця має значення.
Збірка з низьким обсягом-все ще дозволяється навчати. Він не повинен залежати від постійного порятунку.
Якщо план все ще передбачає значне ручне порятунок, повторне інженерне втручання або--інтерпретацію на ходу, тоді проект може бути не настільки готовим до пілотного запуску, як передбачає кількість.
Чому покупці не звертають уваги на ці проблеми
Причина зрозуміла.
Кількість все ще виглядає невеликою, тому конструкція все ще виглядає гнучкою. Проект більше не перебуває в-хаосі першого оберту, тому він виглядає більш зрілим, ніж є насправді. І оскільки пілотний-запуск знаходиться в сірій зоні між перевіркою та виконанням, покупці припускають, що вони можуть відкласти рішення, які насправді потрібно прийняти до початку збірки.
Ось як неправильно-збірку малого обсягу розуміють.
Схоже на «дрібне виробниче замовлення». На практиці це зазвичай перша збірка, де дисципліна пошуку, структура тестування, очищення DFM, глибина документації та чіткість перегляду починають мати значення водночас.
Корисний граничний випадок
Не кожна -маломасштабна збірка потребує однакового рівня дисципліни.
Це правда.
Замовлення на 30-запасних-частин для попередньо перевіреної промислової плати — це не те ж саме, що пілотний запуск із 150 частин для продукту, який може бути масштабований пізніше. Помилкою є припущення, що одна і та ж логіка процесу має застосовуватися до обох просто тому, що жоден не вважається виробництвом великого обсягу.
Чим ближче збірка до реального пілотного рішення, тим менш корисним стає казати: «Це ще невелика серія».
Зазвичай у цьому випадку покупцям потрібно підвищити рівень контролю до початку будівництва, а не після того, як воно починає пробуксовувати.
Що покупці повинні заблокувати перед пілотним запуском
Підтвердьте наявність матеріалів у реальній кількості
Не припускайте, що наявність прототипу означає наявність пілотного проекту. Підтвердьте повну кількість, прийнятні альтернативи та правила затвердження до того, як буде прийнято графік.
Завчасно визначте тестовий шлях
Команда повинна знати, чи все ще реалістичний ручний тест, чи стратегія простого кріплення або літаючого зонда є більш доцільною, і який рівень інспекції чи функціонального покриття насправді очікується.
Робота з налаштування поверхні на початку
Робота, пов’язана з трафаретом, програмуванням,-підготовкою першої статті та-пристосуванням, не повинна викликати сюрпризів лише тому, що партія «не така велика».
Запустіть очищення DFM перед пілотною партією, а не після неї
Пілотна збірка — погане місце для виявлення того, що дизайн усе ще залежить від переробок, яких можна уникнути, слабкого тестового доступу, незручної панелі або рішень макета, які не повторюються чітко.
Посилити контроль документів і перевірок
Пакет збірки, базовий рівень мікропрограми, затверджені заміни та очікування перевірки мають вказувати на одну чисту базову версію версії до випуску партії.
Будьте чесними щодо того, чи запуск перевіряє процес чи все ще рятує дизайн
Ця відповідь змінює спосіб планування, тестування та котирування збірки.
Що це означає для покупців
У -малосерійній збірці друкованої плати перед пілотним запуском покупці часто виявляють, що «невелика кількість» і «просте виконання» — це не одне й те саме.
Найбільш часто забувають про стабільність специфікації за кількістю, масштабування стратегії тестування, видимість вартості налаштування, очищення DFM, глибину документації, контроль змін і реалістичні припущення щодо того, від чого все ще залежить збірка від відновлення вручну.
Це деталі, які зазвичай вирішують, чи пілотний запуск рухається чисто, чи починає поглинати затримку, якої можна уникнути.
Практичний момент простий:
Пілотна -орієнтована-малосерійна збірка — це не просто більший прототип. Це перший етап, на якому повторюваність починає мати значення майже так само, як і функціональність.
Висновок
Якщо ваша команда планує-запуск малого обсягу до випуску пілотної версії, правильне запитання полягає не лише в тому, чи дошка вже працює.
Краще питання полягає в тому, чи готова конструкція тепер до повторення з меншою кількістю імпровізації, меншою двозначністю та меншими прихованими витратами, ніж це було необхідно для прототипу.
Саме там багато розкладів виграно або програно.
Для покупців, які готують низький{0}}запуск до пілотного випуску, практичним наступним кроком є перевірка проекту наЗбірка друкованої платиочікування, підтвердити джерело ризику черезПостачання компонентівлогіку, а потім вирівняйте наступну збіркуЗапит на цінуабо зв’яжіться з командою безпосередньо за адресоюinfo@pcba-china.com.
FAQ
Чому пілотний-малосерійний тест важчий, ніж збірка прототипу тієї самої плати?
Оскільки кількість все ще може бути невеликою, але припущення процесу вже не ті самі. Стабільність матеріалу, узгодженість тестів, контроль версій і робота з налаштування починають мати більше значення, ніж у прототипі.
Що мають підтвердити покупці, перш ніж узяти на себе-згоду складання невеликого обсягу друкованих плат?
Покупці повинні підтвердити наявність повної-кількості матеріалів, фактичний тестовий шлях, статус очищення DFM, узгодженість документів і версій, а також те, чи збірка все ще залежить від ручного відновлення, ніж хоче визнати команда.
Чи зазвичай працює стратегія тестування прототипу для пілотного-орієнтованого малого{1}}запуску?
Не автоматично. Стендове тестування вручну може підійти для кількох плат, але часто воно стає вузьким місцем набагато раніше, ніж очікують команди, коли збірка має на меті підтвердити повторюваність, а не лише першу-успішну роботу.
Чи справді кожна маленька пробіжка є пілотною?
Ні. Замовлення-запасних частин для перевіреної плати дуже відрізняється від-малосерійної збірки, яка призначена для підтримки реального пілотного рішення. Покупці часто втрачають час, коли планують обидва з однакових припущень.
