09:28 RFI або RFP для виявлення дронів має перетворювати затверджену модель загрози, базу об’єкта та робочий процес на вимірювані відповіді постачальників. Не слід просити постачальників тлумачити невизначену місію або покладатися на рекламні терміни, такі як «виявлення на 360 градусів», «класифікація ШІ» або «зв’язок із камерою». Кожна обов’язкова вимога потребує поля для відповіді, джерела доказів, відповідальної особи та методу прийняття. Використовуйте батьківський Посібник з закупівлі радарів для виявлення дронів та спостереження на низьких висотах затвердити модель загрози, архітектура сенсора та на місці перед видачею цього документа.
Як написати RFI/RFP для системи радарного виявлення дронів
Якщо ці пункти не затверджено, RFP збере несумісні рішення, а не порівнянні відповіді. Спочатку вирішіть базову версію, а потім дозвольте постачальникам пропонувати відповідні альтернативи з чітко визначеними відхиленнями.
RFP повинен зазначати, які докази та документи доставки має надати кожен учасник. Мета не в тому, щоб ранжувати постачальників у цьому посібнику; мета – запобігти перетворенню нечітких тверджень на неперевірені умови контракту.
| Необхідна категорія доказів | Обов'язкова подача RFP |
| Порівнянні свідчення розгортання | Проєкти-приклади з подібними цілями, середовищем, архітектурою та масштабом; контактні дані лише там, де дозволено їх розкриття. |
| Докази ефективності | Звіти випробувань, що зазначають метод вимірювання, конфігурацію, визначення цілі, умови експлуатації, наявність сирих даних та обмеження. |
| Інженерні результати | Модель покриття, проектування інтерфейсу, монтажні креслення, метод введення в експлуатацію, план калібрування та відповідальність за усунення несправностей. |
| Пакет інтерфейсу | Контрольовані документи, зразки повідомлень, визначення полів, тестові інструменти, підтримувані версії, процес контролю змін та призначений власник інтеграції. |
| Документи щодо якості та відповідності | Тільки документи про якість, екологію, електромагнітну сумісність (ЕМС), радіо, безпеку та доступ до ринку, застосовні для кінцевої країни, для запропонованої конфігурації. |
| Результати кібербезпеки | Межі архітектури, модель контролю доступу, політика оновлень, звітування про вразливості, ведення журналів, правила віддаленого доступу та управління оновленнями. |
| Підтримка результатів | Час реагування, дистанційна діагностика, умови на місці, план запасних частин, план навчання, шлях ескалації та політика повідомлення про припинення підтримки. |
| Заява про підтримку життєвого циклу | Період підтримки програмного забезпечення, політика сумісності, обов'язкові ліцензії, шлях оновлення, потреби у калібруванні та період доступності запасних частин. |
| Комерційна декларація | Включені елементи, виключення, припущення, залежності, повторювані витрати, обов'язки покупця, правила змін та етапи, пов'язані з прийняттям. |
Не приймайте загальних заяв, таких як «використовується у всьому світі», «точність ШІ понад 95%» або «майже нульова кількість хибних тривог», як достатні відповіді. Вимагайте вказати цільові класи, датасет або підставу польових випробувань, середовище, конфігурацію системи, поріг впевненості, обмеження та названого власника документа. Вимоги до доказів повинні бути однаковими для кожного респондента і мати статус частини технічного контракту там, де це доречно.
Кожна вимога повинна мати унікальний ідентифікатор та поля для стану відповідності, запропонованої цінності, умови або обмеження, документу-доказу, ревізії документу, відповідальної організації та запропонованого методу прийняття. Не об'єднуйте кілька технічних вимог в одну рядок з відповіддю «так/ні», оскільки часткова відповідь стає неможливою для оцінки.
| Поле | Обов'язковий запис постачальника |
| Ідентифікатор вимоги | Контрольований покупцем референс, незмінний у всіх відповідях |
| Відповідність | Відповідає / Відхилення / Необов'язкова альтернатива / Не пропонується |
| Пропонована цінність | Числова або вимірювана відповідь; уникайте маркетингової мови |
| Умови | Ціль, середовище, конфігурація, ліцензія або припущення щодо інфраструктури |
| Доказ | Технічний опис, креслення, документ інтерфейсу, звіт про тестування або контрольована демонстрація |
| Відповідальність | Постачальник, покупець, третя сторона або спільна відповідальність |
| Метод прийняття | Огляд документів, FAT, польове випробування, SAT або операційне спостереження |
Як написати RFI/RFP для системи радарного виявлення дронів
Технічний паспорт продукту може підтримати відповідь, але він не визначає весь проект. Запит на пропозицію повинен окремо запитувати (RFP) radar sensor, сервер та програмне забезпечення, ліцензії, EO/IR integration, зовнішні інтерфейси, інженерія майданчика, щогли та цивільні роботи, кабелювання, введення в експлуатацію, навчання, документація, запчастини, гарантія та підтримка. Це запобігає тому, щоб низька ціна обладнання була помилково сприйнята як повноцінна операційна система.
У RFP повинно вимагатись повного графіка розкриття інформації, щоб пізніші пропозиції могли бути стандартизовані без здогадок про те, що включено. Графік повинен ідентифікувати обладнання, інфраструктуру, інженерію, інтеграцію, розгортання, повторювані послуги, обслуговування, припущення, винятки та обов’язки покупця.
| Група розкриття | Інформація, яку повинен зазначити кожен постачальник |
| Обладнання | Радар, RF, EO/IR, сервери, сховища, мережеві пристрої, робочі станції операторів, аксесуари та запчастини; вказати кількість та конфігурацію. |
| Інфраструктура | Щогли, фундаменти, укриття, електроживлення, джерела безперебійного живлення (UPS), заземлення, блискавкозахист, оптоволокно, бездротові канали та межі цивільних робіт. |
| Інженерія | Опитування, проектування, моделювання покриття, креслення, огляд кібербезпеки, управління проектами та обов'язки з перегляду документів. |
| Інтеграція | Драйвери, робота API, інтерфейси VMS/PSIM/C2, перетворення координат, тестове середовище, тестування, документація та сторонні залежності. |
| Розгортання | Вантаж, страховка, митне оформлення, встановлення, введення в експлуатацію, калібрування, підтримка при прийманні та обов'язки в країні призначення. |
| Повторювані послуги | Ліцензії, підключення, хмарні або моніторингові послуги, зберігання даних, обов’язкова підтримка програмного забезпечення та умови його поновлення. |
| Обслуговування та підтримка | Профілактичне обслуговування, калібрування, запчастини, логістика ремонту, оновлення програмного забезпечення, віддалена підтримка та умови обслуговування на місці. |
| Припущення та виключення | Обладнання, надане покупцем, умови на майданчику, додаткові датчики, вищі щогли, переміщення, модифікації сторонніх осіб, повторне тестування та правила контролю змін. |
Цей посібник не обчислює і не ранжує витрати життєвого циклу. Він лише визначає інформацію, яку повинен розкривати кожен постачальник. У ньому слід вказати технічне обслуговування, надлишковість, запаси, регіон підтримки, наслідки простою та програмні зобов'язання, специфічні для архітектури, з припущеннями та доказами; окремий посібник з порівняння цитат тоді слід оцінити ці розкриття на рівних умовах.
Вимагайте від кожного респондента заповнити той самий графік. Порожня відповідь, «TBD» або «підтримано» залишається невирішеною вимогою, поки не буде надано конкретне твердження, джерело доказів та відповідальна особа. Заповнений графік створює спільну базову лінію, яка пізніше використовується для порівняння котирувань.
| Група вимог | Обов'язкова відповідь постачальника |
| Операційна сфера | Тільки виявлення, DTI або інтегрований межа C-UAS; включені та виключені функції |
| Цілі | Еталонні цілі, профілі польоту, швидкості, висоти та умови експлуатації |
| Радарні характеристики | Виявлення, ініціація відстеження, стабільне відстеження, покриття, оновлення, точність, місткість та класифікація |
| Архітектура сенсора | Радар, RF, EO/IR, кооперативні дані та ролі інтеграції |
| Дизайн покриття | Кількість датчиків, положення, висоти, мертві зони, перекриття та припущення |
| Інтеграція | Інтерфейси, формати, координатні системи, синхронізація часу, camera cueing, health and logs |
| Кібербезпека | Контроль доступу, шифрування, сегментація, встановлення оновлень, аудит та віддалена підтримка |
| Інфраструктура | Мачти, цивільні роботи, електропостачання, мережа, заземлення, укриття та охорона навколишнього середовища |
| Тестування | Методи приймання на заводі, у полі та на об'єкті, цілі, дані, порогові значення та правила повторного тестування |
| Підтримка | Навчання, гарантія, SLA, діагностика, запчастини, технічна підтримка програмного забезпечення та політика щодо завершення експлуатації |
| Комерційний | Деталізований розклад цін, включені елементи, повторювані витрати, припущення, виключення, обов’язки покупця, графік доставки, етапи платежів та правила контролю змін; у цьому посібнику немає зваженого оцінювання. |
| Відповідність | Відповідальність за радіо, ЕМС, безпеку, авіацію, імпорт/експорт та документацію, специфічна для призначення |
Вимагайте, щоб кожне відхилення ідентифікувало уражену вимогу, операційні наслідки, запропоновану альтернативу, вплив на ціну та наслідки прийняття. Припущення повинні бути консолідовані в одному реєстрі, а не розкидані по всій пропозиції. Опціональні альтернативи повинні оцінюватися окремо і не можуть використовуватися для приховування невідповідності обов’язковій вимозі.
Як написати RFI/RFP для системи радарного виявлення дронів
Після отримання перевірте кожну відповідь у три етапи. По-перше, ідентифікуйте обов’язкове невиконання вимог та відсутні докази. По-друге, видайте контрольований журнал уточнень, який зберігає оригінальний ідентифікатор вимоги та фіксує відповідь постачальника, вплив та статус закриття. По-третє, відокреміть відповідний базовий обсяг від необов’язкових переваг перед оцінкою за ціною. Це запобігає тому, щоб технічно неповна пропозиція виглядала конкурентоспроможною лише через меншу ціну або більш активну маркетингову підтримку.
Уточнення, які змінюють запропонований обсяг, умови виконання, відповідальність або ціну, слід включити до фінальної пропозиції та додатку до контракту. Пояснення електронною поштою, які не перенесені у контрольовану пропозицію, не слід вважати обов’язковими зобов’язаннями щодо постачання.
Призначте відповідального за кожну вимогу, інтерфейс та графік подання доказів. Видайте один контрольований базовий документ усім респондетам, ведіть журнал усіх прояснень і визначайте, чи змінює кожна відповідь відповідність, ціну, терміни або прийняття. Перед укладанням контракту інтегруйте прийняті пояснення та відхилення у кінцевий технічний графік, щоб оцінена пропозиція та контракт описували одну й ту ж систему.
Обґрунтований запит на пропозицію щодо виявлення дронів є контрольованою системою реагування. Він надає кожному постачальнику однакові ID вимог, очікування доказів, поля відповідальності, комерційні розкриття та методи прийняття. Після отримання відповідей, що відповідають вимогам, покупець може перейти до окремого етапу порівняння комерційних пропозицій без необхідності відновлювати фактичний зміст кожної пропозиції. (RFP)
Зазвичай ні. Спочатку вкажіть необхідний операційний результат, встановлені цілі, інтерфейси та критерії прийняття. Модель може бути названа лише тоді, коли це вимагають сумісність, стандартизація або затверджений дизайн.
Звіт контрольного тесту, документ інтерфейсу, креслення покриття, витяг сирих даних або жива демонстрація, пов'язані з запропонованою конфігурацією та зазначеними умовами експлуатації.
На початковому етапі контрольованої реакції. Виключення, виявлені під час переговорів або встановлення, створюють уникнений ризик зміни замовлення та графіка.
Матеріально-технічні відповіді, креслення, припущення, відхилення, результати постачання та зобов’язання щодо прийняття повинні бути включені до контракту або його контрольованих додатків.
Ми відповімо вам протягом 24 годин. У разі термінового випадку, будь ласка, додайте WhatsApp/WeChat: 86 86 13361376820, або телефонуйте безпосередньо 86 86 13361376820.
*Ми поважаємо конфіденційність, і вся інформація захищена.
Ми використовуватимемо вашу інформацію лише для відповіді на запит і ніколи не надсилатимемо небажаних електронних листів або рекламних повідомлень.
