Управління конфігурацією у AQAP 2110: практичний гід для виробника оборонної продукції (2026)

Управління конфігурацією AQAP 2110 (Configuration Management, CM) — це дисципліна, яка тримає під контролем фізичний і функціональний склад виробу впродовж усього життєвого циклу: від першого ескізу до утилізації останньої одиниці партії через 20 років після поставки. На практиці CM відповідає на одне просте запитання, яке аудитор-замовник ставить найчастіше: «Що саме ви виробили в цій партії, і чим вона відрізняється від попередньої?». Якщо команда інженерів не може за 15 хвилин показати точну версію кожного компонента, кожної прошивки і кожного креслення для конкретного серійного номера — у вас немає CM, як би красиво не виглядали папери.

Для цивільного виробника така прозорість — приємний бонус. Для defense-постачальника це питання безпеки, контрактних зобов'язань і ремонтопридатності на горизонті 10-30 років. Снаряд, дрон чи система зв'язку, поставлені у 2026, можуть стояти на озброєнні до 2050-х. Через десять років замовник прийде з відмовою бойового зразка, і ви повинні точно знати, з якої партії плата, від якого постачальника мікросхема, яка була прошивка на момент випуску і чи потрапили інші вироби з цієї ж партії під підозру.

AQAP 2110 закладає п'ять процесів CM, які треба запустити паралельно: Configuration Identification (ідентифікація), Baseline Management (фіксація базових станів), Change Control (контроль змін), Configuration Status Accounting (статус-облік) і Configuration Audits (FCA і PCA). Це безпосереднє запозичення з NATO ACMP-2100 (NATO Configuration Management Policy) і фактично відтворює модель американського MIL-STD-973 та ANSI/EIA-649. Стандарт EIA-649 — основна індустріальна довідка з CM, на яку посилаються більшість defense-програм Альянсу.

Саме тут проходить найбільший розрив між AQAP 2110 і ISO 9001. У ISO 9001:2015 управління конфігурацією явно не вимагається — є лише натяки в розділі 8.5.2 «Ідентифікація та простежуваність». В AQAP 2110 CM — окремий обов'язковий блок з пунктом 8.1.4 і прив'язкою до ACMP-2100, без якого сертифікат не видається. Тому компанія, яка переходить від ISO 9001 до AQAP 2110, має закласти CM з нуля або суттєво доопрацювати наявні шматки. Деталі цього переходу розібрані в порівнянні AQAP 2110 і ISO 9001, а загальна логіка стандарту НАТО — у повному посібнику AQAP 2110.

Перший крок CM — рішення, що саме у вашому виробі є окремим Configuration Item (CI). CI — це будь-яка частина виробу, яку треба окремо ідентифікувати, версіонувати і контролювати у часі. Не все треба робити CI: гайка М6 з ГОСТ 7798 — це не CI, бо взаємозамінна у необмеженому обсязі. А ось плата керування польотом FPV-дрона — обов'язково CI, бо її версія напряму впливає на сумісність прошивки, поведінку в польоті і характеристики виробу.

Для виробника БпЛА типова декомпозиція виглядає так: на верхньому рівні CI — повна збірка дрона (наприклад, «FPV-X-2026-Rev3»). Нижче — головні підсистеми: планер, силова установка, плата керування, відеотракт, прошивка польотного контролера, прошивка ELRS-приймача. Ще нижче — критичні компоненти: оптика камери, мотори, ESC, акумулятор тактичного класу. Документ tree (дерево документації) показує, як креслення, специфікації, BOM і робочі інструкції зв'язані з кожним CI на кожному рівні.

Numbering scheme — окрема тема, до якої треба підходити серйозно. Хороший part number включає тип виробу, ревізію, варіант комплектації і модифікацію. Поганий part number — просто наскрізна цифра без структури, бо через 200 одиниць ви заплутаєтесь. Аудитор Bureau Veritas на стадії передаудиту майже завжди питає: «Покажіть мені правила формування part number, і дайте розшифровку для 3 випадкових серійних номерів з останньої партії». Якщо команда не може цього зробити швидко — це провал по configuration identification ще до Stage 2.

Компанії, які виробляють дрони і потребують AQAP 2110, часто недооцінюють обсяг CI tree. Здається — «у нас простий FPV, там 50 деталей». На практиці після формалізації виходить 80-150 CI з урахуванням прошивок, варіантів комплектації і конструкторської документації. Це нормально. Більше CI — більше прозорості, менше CI — більше білих плям, у які потім поб'є аудитор.

Baseline — це формально схвалений знімок стану конфігурації виробу на конкретну дату. До baseline ви ще шукаєте, експериментуєте, змінюєте все вільно. Після baseline кожна зміна йде через формальну процедуру Change Control. У термінології ACMP-2100 розрізняють чотири типи baselines: Functional Baseline (затверджені функціональні вимоги після SRR — system requirements review), Allocated Baseline (розподіл вимог по підсистемах після PDR — preliminary design review), Product Baseline (повна конструкторська документація після CDR — critical design review) і Operational Baseline (стан виробу в експлуатації, оновлюваний з кожною модифікацією).

Хто затверджує baseline? Configuration Control Board (CCB) — постійний міжфункціональний орган у компанії, який збирається регулярно (зазвичай раз на тиждень або раз на два тижні) і голосує за всі baseline-події. Мінімальний склад CCB у defense-виробника: головний конструктор, керівник виробництва, керівник якості, представник постачання і — для серйозних замовлень — представник замовника або його уповноважений (GQAR). Без формального протоколу CCB baseline не вважається затвердженим, навіть якщо інженер впевнено каже «ну ми ж усе обговорили».

Де зберігати baseline технічно? Тут є два підходи. Перший — централізована PLM-система (Aras, Teamcenter, Windchill, Odoo PLM): дорого, повільно впроваджується, але дає індустріальний рівень контролю версій. Другий — Git-подібний підхід: репозиторій документів з версіонуванням, теги для baseline, pull request як механізм Change Control. Для команди до 30 інженерів другий варіант часто практичніший і дешевший. Аудитор не зобов'язує конкретну технологію — головне, щоб версії не губилися, історія була повна, а права доступу — контрольовані.

Коли встановлювати перший baseline? Не одразу після ескізу. Не за тиждень до Stage 2. Правильний момент — після Critical Design Review, перед першою партією повноцінного серійного виробництва. До цього моменту виріб ще змінюється швидко, і фіксувати все формально — лише марна бюрократія. Після CDR — навпаки, кожна зміна має ціну для замовника, тому контроль життєво необхідний.

Change Control — це серце CM, і саме тут ламається більшість українських defense-виробників на першій спробі сертифікації. Інженери звикли вносити зміни швидко, на словах, через Telegram-чат: «слухай, поміняй опір з 10к на 4.7к, потестую і скажу». В AQAP 2110 така зміна — критична невідповідність, бо немає сліду, немає impact analysis, немає схвалення CCB і немає оновлення документації.

Правильний цикл починається з Engineering Change Request (ECR) — формальної заявки на зміну. ECR подає будь-хто з команди, але обов'язково з обґрунтуванням: чому потрібна зміна (помилка проєкту, поліпшення, вимога замовника, недоступність компонента), що саме змінюється і на що це вплине. CCB на найближчому засіданні проводить impact analysis: вартість, графік (чи буде затримка партії), вплив на продуктивність виробу, ризики безпеки, юридичні наслідки за контрактом. На цьому етапі більшість ECR відхиляються — і це нормально, бо CCB фільтрує справжні зміни від хотілок.

Якщо ECR схвалено, формується Engineering Change Notice (ECN) — документ з повним технічним описом зміни і оновленою конструкторською документацією. ECN йде у виробництво через Engineering Change Order (ECO), де вказана точна точка впровадження: з якої партії або серійного номера зміна вступає в дію, що робити з вже виробленими виробами (rework, retrofit чи нічого), як оновити робочі інструкції на лінії. На повний цикл ECR → CCB → ECN → ECO зазвичай йде від 5 робочих днів (для нескладних змін) до 4-6 тижнів (для змін, що вимагають погодження з замовником).

Верифікація — фінальний крок. Після впровадження ECO відділ якості перевіряє, що зміна реально потрапила у вироби, документація оновлена синхронно, постачальники компонентів отримали нові специфікації. Без верифікації ECO висить «в повітрі» — формально зміна затверджена, реально половина лінії все ще виробляє за старим кресленням. На захист аудитор Bureau Veritas майже завжди бере 3-5 свіжих ECO і перевіряє, чи реалізовані вони в виробництві. Якщо реалізації немає — це автоматично major nonconformity.

Configuration Status Accounting (CSA) — це база знань усієї історії конфігурації виробу. Простими словами: для будь-якої партії, виробленої вчора чи три роки тому, ви маєте за 10-15 хвилин відновити повну картину — які саме версії CI використовувалися, які ECO діяли на момент випуску, які постачальники постачали критичні компоненти, де зберігається відповідний baseline.

Центральний документ CSA для defense-виробника — Configuration Identification Card (картка конфігурації), або в українській практиці «картка конфігурації виробу». Це defense-специфічний документ, якого немає в стандартному ISO 9001-наборі. Картка прив'язана до партії виробництва (а не до окремого виробу — інакше документообіг втопить компанію) і містить: номер партії, дату випуску, обсяг партії, список усіх CI з точними версіями на момент випуску, посилання на baseline, перелік активних ECO, прізвища відповідальних інженерів і керівника якості, місце зберігання повної проєктної документації для цієї версії.

Як аудитор перевіряє CSA на практиці? Бере випадково 2-3 партії з виробничого журналу за останні 6 місяців, запитує картку конфігурації, далі іде на склад або в цех і перевіряє відповідність кільком фізичним зразкам. Якщо картка каже «прошивка v2.4.1», а на дроні фактично v2.3.0, це автоматично major nonconformity. Якщо картка взагалі відсутня для готової партії — це автоматичний провал Stage 2, без шансів виправити на місці.

CSA також забезпечує impact analysis у зворотний бік: коли вилазить дефект через рік експлуатації, ви маєте швидко знайти, які ще партії використовували проблемний CI або проблемну версію прошивки. Без CSA єдиний шлях — recall усього випуску, що для defense-виробника може означати багатомільйонні збитки і втрату довіри замовника. Повний перелік документів CM-блоку розібраний у чек-листі документів для AQAP 2110 — це корисний компаньйон до цього гіду.

Configuration Audits — фінальний механізм перевірки CM-системи, і вони часто плутаються з звичайними аудитами якості. Це окремий вид перевірки, передбачений ACMP-2100, з власною методологією. Розрізняють два формати, які зазвичай проводяться послідовно.

Functional Configuration Audit (FCA) — перевірка, чи виріб реально виконує функціональні вимоги, зафіксовані в Functional Baseline. Аудитор бере вихідні специфікації (наприклад, «дрон витримує політ 30 хв при -15°C з повним корисним навантаженням») і тестує реальний виріб. Якщо тести проходять — FCA закриває фрагмент функціональних вимог. Якщо ні — це або помилка специфікації (треба формальне ECR), або реальний дефект конструкції (треба CAPA). FCA проводять зазвичай після завершення випробувань першого виробу і до запуску серійного виробництва.

Physical Configuration Audit (PCA) — перевірка, чи фізична реалізація виробу відповідає документації Product Baseline. Аудитор бере перший виріб серійної партії, розбирає (за погодженням), порівнює кожен компонент із BOM, кожну плату — з електричною схемою, кожен механічний вузол — з кресленням. Знаходять навіть дрібні розходження — наприклад, технолог замінив гвинт M3 на M3.5 «бо так зручніше», але документація не оновлена. PCA закриває фрагмент конструкторської і виробничої документації як «синхронізований з реальним виробом».

Хто проводить FCA і PCA? Для українських компаній — або сам замовник (Міноборони, NSPA, MoD країни НАТО) під час замовницького аудиту, або уповноважена третя сторона (Bureau Veritas, наприклад). Часто FCA і PCA поєднують з замовницьким аудитом перед першою партією поставки — це раціональний підхід, бо замовник усе одно перевіряє відповідність специфікаціям і документації. Готуватися до FCA/PCA треба окремо: підняти все, що CCB схвалив, прибрати з лінії все, що не відповідає поточному baseline, мати під рукою повний пакет конструкторської документації за активною версією.

За 200+ defense-проєктів, які пройшли через нашу команду, виокремлюються одні й ті самі помилки. Майже кожна — наслідок «зробимо CM пізніше», коли пізніше виявляється «ніколи». Розглянемо п'ять найчастіших.

Перша і найпоширеніша — «у нас CM ведеться в Excel-табличці». Excel сам по собі не проблема (хоча PLM кращий), проблема — у відсутності формальної процедури затвердження змін. Хтось редагує, інший не бачить, версія втрачається при перезбереженні. На питання аудитора «хто і коли затвердив зміну на v2.3» команда відповідає «ну ми всі обговорили на скайпі». Це автоматичний провал по change control.

Друга — зміни в кресленнях без оновлення робочих інструкцій. Конструктор оновив креслення в системі, відправив на виробництво, технолог надрукував і повісив на лінію — а робоча інструкція операторам залишилася старою. Через місяць на аудиті оператор робить за інструкцією, технолог каже «треба інакше», на лінії хаос. Це не помилка людей, це помилка процесу: ECO має включати оновлення ВСІХ пов'язаних документів, не лише креслення.

Третя — версії документів на принтері і в системі не збігаються. Класичний симптом: на лінії висить креслення «v2.1» з підписом 2024 року, в системі найсвіжіша «v2.5» з 2026. Оператор робить за тим, що бачить. Рішення — або повна цифровізація з тонкими клієнтами на робочих місцях, або жорсткий процес заміни паперових копій з документованим знищенням попередньої версії.

Четверта і критична для defense — картка конфігурації відсутня для готових партій. Часто компанія робить CM для прототипів і пілотних партій, а на серійному виробництві «забуває». Партії на склад іде без картки, бо «це ж рутина». Аудитор питає картку — її немає. Major nonconformity, і часто це блокує сертифікацію до повторного аудиту.

П'ята — зміни в ПЗ без CM-процесу, особливо болюча для виробників дронів. Embedded-розробник пушить коміт у Git, збирає прошивку, ставить на лінію тестування — без ECR, без CCB, без ECO. Прошивка — це повноцінний CI, і вона підпадає під CM повністю так само, як плата чи механічний вузол. Окремий пункт головного болю — як рахувати CM-вартість, бо це часто непомітна стаття витрат. Деталі економіки розібрані в гіді з вартості сертифікації AQAP 2110. Для виробників оборонної промисловості витрати на CM окупаються вже на першому-другому експортному контракті.