RFI, RFP чи RFQ: як обрати підрядника для інтернет-магазину

RFI, RFP чи RFQ варто обирати не за розміром бюджету, а за тим, чого ви ще не знаєте про майбутній інтернет-магазин. Якщо незрозумілі можливості ринку — потрібна інформація. Якщо результат визначений, але спосіб його досягнення відкритий — потрібні пропозиції рішення. Якщо обсяг і умови вже узгоджені — можна запитувати зіставні ціни.

Помилка виникає, коли бізнес надсилає кільком командам прохання «оцінити магазин з інтеграцією ERP» і порівнює підсумкові суми. Одна команда враховує лише передавання замовлень, інша — ще залишки, повернення та відновлення після збоїв. Різниця в ціні тоді показує різний обсяг припущень, а не різну ефективність розробників. Правильний запит має зробити ці припущення видимими до договору.

1. Почніть із невизначеності, а не з назви документа

Разом із керівниками продажів, маркетингу та відповідальним за облікову систему запишіть, що магазин повинен змінити: дати дилерам персональні ціни, прибрати ручне перенесення замовлень чи підтримати кілька складів. Розділіть відомі факти, побажання та питання без відповіді.

Наприклад, для показу залишку потрібно з’ясувати, яка система керує резервом, наскільки свіжими мають бути дані та що бачить покупець під час збою. Доки це невідомо, фіксований кошторис створює хибну точність. Спершу потрібне дослідження.

2. Чим відрізняються RFI, RFP та RFQ

RFI означає Request for Information — запит інформації; RFP, Request for Proposal — запит пропозицій; RFQ, Request for Quotation — запит цінової пропозиції. У настановах New Zealand Government Procurement ця відмінність пов’язана з метою закупівлі: дослідити ринок, отримати спосіб досягнення результату або оцінити вже визначене постачання. Для українського приватного бізнесу нижче наведено практичну адаптацію, а не обов’язкову іноземну процедуру.

Це не обов’язковий ланцюжок із трьох конкурсів. Якщо ринок і задача зрозумілі, переходьте одразу до RFP. Якщо всі суттєві умови вже визначені — до RFQ. Навіть великий бюджет не робить запит пропозицій потрібним автоматично, а невеликий не усуває технічної невизначеності.

3. RFI: отримайте знання, яких бракує замовнику

Короткий RFI доречний, коли ви не розумієте, чи вистачить готового рішення, чи потрібна індивідуальна розробка. Опишіть модель продажів, ролі покупців, чинні системи, стан каталогу та обмеження запуску. Попросіть пояснити можливі підходи, їхні компроміси, потрібні доступи й те, що неможливо оцінити без дослідження. Орієнтовний бюджет можна обговорити, але він не замінює майбутнього кошторису.

Питайте про межі, а не про кількість функцій

Замість «чи інтегруєте ви ERP?» запитайте: «Які дані та документація потрібні, щоб оцінити обмін цінами, залишками й замовленнями?». Замість «чи масштабується система?» — «Які параметри навантаження потрібно виміряти до вибору архітектури?». Корисна відповідь називає умови й невідомі, а не просто підтверджує всі побажання.

Результат RFI — уточнений бриф, альтернативи та перелік перевірок. Повідомте, що це дослідження, а не вибір переможця. Детальне проєктування чи прототип потребують окремо погодженого обсягу, а не безкоштовного виконання в межах відповіді.

4. RFP: зробіть різні рішення порівнюваними

У RFP задайте спільний контекст, але залиште місце для аргументованих альтернатив. Потрібні цілі, межі першого запуску, основні сценарії, перелік систем, вимоги до перенесення даних і критерії приймання. Позначте обов’язкове окремо від бажаного. Якщо технологію не визначено, попросіть пояснити вибір; якщо визначено, наведіть реальне обмеження, а не лише назву платформи.

Одна форма відповіді для всіх команд

Підготуйте матрицю: ідентифікатор вимоги, спосіб реалізації, що входить у ціну, залежність від замовника, виняток і доказ виконання. Для функції відповідь має відрізняти готову можливість, налаштування, індивідуальну розробку та зовнішній сервіс. Фраза «підтримується» без цих уточнень приховує майбутні витрати.

Попросіть розбити ціну на аналіз, дизайн, розробку, інтеграції, міграцію, тестування, запуск і підтримку. Відокремте базовий обсяг від опцій. Для регулярних витрат узгодьте спільний період порівняння, валюту, податки та обсяг використання сервісів.

До отримання відповідей визначте критерії оцінювання: покриття критичних сценаріїв, якість доказів, керованість інтеграцій, команда, підтримка й сукупна вартість. Ваги оберіть під власні ризики, а не за універсальною формулою. Питання учасників та загальні уточнення до вимог передавайте всім в однаковій редакції, не розкриваючи чужих комерційних даних.

Окремо перевіряйте, хто саме виконуватиме роботи, як погоджуються зміни та хто відповідає за сторонніх виконавців. Відомості про компанію GL.ua (Глянець), як і корпоративна сторінка іншого кандидата, дають контекст, але не замінюють перевірки конкретної команди та її пропозиції.

5. RFQ: запитуйте ціну лише за визначеними межами

Для RFQ потрібні однаковий результат, специфікація, тестові дані та правила приймання. Якщо кожна команда сама визначає логіку знижок чи склад міграції, ціни не будуть зіставними.

Вкажіть версію специфікації. Попросіть зазначити строк чинності ціни, винятки, оплату, залежності від доступів та порядок зміни обсягу. Уточніть, чи входять виправлення дефектів, розгортання, документація й передавання результату.

Якщо учасники повертають запитання замість ціни, уточніть обсяг або винесіть невідомий компонент в окремий аналіз. RFQ може стосуватися визначеної частини робіт, а не всього магазину.

6. Перевірте ризикову інтеграцію до основного договору

Презентація готового магазину показує інтерфейс, але не доводить надійність обміну з вашою обліковою системою. Для найризикованішого сценарію погодьте обмежену технічну перевірку: прототип, тест обміну або аналіз реальної документації. Це окрема робота з результатом, доступами та критеріями завершення, а не вимога безкоштовно створити частину продукту.

1. Оберіть критичний потік: товар і ціна з облікової системи, замовлення з магазину, підтвердження оплати та зміна статусу. Назвіть власника кожного типу даних.
2. Надайте тестове середовище, документацію API — інтерфейсу обміну між системами — і знеособлені приклади. Перевірте дозволи та обмеження частоти запитів.
3. Зафіксуйте очікуваний результат для звичайного проходження, відмови, затримки та повторного повідомлення. Визначте, як звірити записи по обидва боки.
4. Відтворіть збій з’єднання й повторне надсилання. Перевірте, чи не виникли дублікати замовлення або резерву та як оператор дізнався про помилку.
5. Отримайте журнал перевірки, перелік обмежень і висновок: підтверджено, потрібна зміна підходу або даних недостатньо. Оновіть оцінку й критерії приймання.

Захист від повторного виконання операції називають ідемпотентністю. Наприклад, документація Stripe про повторні API-запити описує застосування ключа для безпечного повторення операції. Це приклад механізму, а не доказ, що ваша ERP має такий самий захист: поведінку конкретної інтеграції потрібно перевірити окремо.

Безпека також потребує доказів

Software Acquisition Guide від CISA розглядає оцінювання практик постачальника протягом життєвого циклу ПЗ. Для магазину практичні питання стосуються доступів, залежностей, оновлень і реагування на вразливості. Це корисна рамка розмови, а не вимога виконувати американські державні процедури.

Замість «сайт має бути безпечним» погодьте, хто перевіряє права ролей, захист адміністративного доступу та відновлення резервної копії. OWASP ASVS можна використати як основу конкретних вимог до перевірки. Назвіть версію, застосовні вимоги та докази; саме посилання на стандарт ще не підтверджує відповідність.

7. Порахуйте строки, вартість і ціну невідомих

Календар залежить не лише від розробників. На нього впливають готовність каталогу, погодження дизайну, доступ до ERP, участь платіжного провайдера, очищення даних і доступність людей замовника. Вимагайте план із залежностями та відповідальними: що можна робити паралельно, що блокує наступний етап і коли повторно перевіряють оцінку. Загальна дата без цих умов мало допомагає керувати запуском.

Порівнюйте не тільки створення, а й володіння магазином. У розрахунку окремо покажіть бізнес-аналіз, проєктування, дизайн, розробку, обмін даними, міграцію, перевірки та навчання. До регулярних витрат належать інфраструктура, платні сервіси, моніторинг, оновлення й підтримка. З’ясуйте, які платежі залежать від замовлень, користувачів або обсягу даних і хто укладає договори з цими сервісами.

Для невідомих робіт попросіть не приховану надбавку, а пояснення: що саме невідомо, як це з’ясувати та коли зміниться оцінка. Фіксована ціна не усуває нечітких вимог, а погодинна оплата не скасовує контролю бюджету. Для обох моделей потрібні межі, звітність і порядок погодження змін. Комерційні та юридичні умови перевіряйте з відповідальними фахівцями; ця стаття не є юридичною консультацією.

8. Обирайте за перевіреним результатом, а не за обіцянкою

Перед фінальним рішенням поверніться до матриці вимог. Неприйнятний ризик у критичній інтеграції не варто компенсувати красивішим дизайном або нижчою сумою. Водночас прототип не доводить готовність усього магазину до пікового навантаження: він лише знімає визначену невідомість. Решта сценаріїв потребуватиме власних перевірок під час розробки й запуску.

Зафіксуйте погоджені уточнення в робочому обсязі, а не залишайте їх у листуванні. Визначте критерії приймання, відповідальних за дані й доступи, правила підтримки та передачі коду, документації і налаштувань. Не передавайте учасникам продуктивні паролі чи повні клієнтські бази заради оцінювання. Для початкової перевірки використовуйте обмежені доступи та знеособлені дані.

Добрий результат відбору — не найдовший RFP, а пропозиція, де видно виконуваний обсяг, підтверджені можливості та залишкові ризики. Якщо готуєте новий магазин або міграцію, обговоріть розробку інтернет-магазину з GL.ua: передайте бізнес-сценарії, перелік систем і відкриті питання, щоб почати розмову з реальної задачі, а не з непорівнюваних цін.