Тендер на IT-розробку для компанії

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

Нижче порядок тендеру на IT-розробку, який дає порівнянні пропозиції: від запиту до договору.

Крок 0. Вирішіть, чи задача готова до тендеру

Тендер на розробку має сенс, коли задачу можна описати так, щоб учасники зрозуміли її однаково. Якщо відомо лише бажання («автоматизувати відділ продажів»), пропозиції будуть різнитися на порядок, і порівнювати їх не вийде.

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

Крок 1. Запит пропозицій

Запит пропозицій має відповісти учасникам на питання, які вони інакше закладуть запасом у ціну. Структура:

1. Про компанію і контекст. Сфера, розмір, чому зʼявилася задача.
2. Мета і результат. Що має змінитися в бізнесі після запуску.
3. Користувачі і сценарії. Хто працює з системою і що робить.
4. Інтеграції. З якими системами повʼязана розробка, чи є API, хто дасть доступ.
5. Дані. Які дані обробляються, де мають зберігатися, вимоги служби безпеки.
6. Обмеження. Строки, бюджетні рамки, технології, які використовуються в компанії.
7. Що очікується в пропозиції. Підхід, план етапів, команда, кошторис за формою, гарантія, супровід, приклади робіт.
8. Порядок тендеру. Строки питань і відповідей, строк подання, критерії з вагами, контакт для питань.

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

Крок 2. Єдина форма кошторису

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

Попросіть окремо вказати, що не входить у пропозицію (ліцензії, хостинг, контент, навчання), і чи години нетто. Кожна сума в пропозиції має дорівнювати сумі рядків. З такою формою видно, хто заклав тестування, хто пропустив інтеграцію і де ставки різняться.

Крок 3. Критерії з вагами

Опублікуйте критерії і їхні ваги до подання пропозицій. Приклад набору критеріїв:

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

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

Крок 4. Питання і відповіді письмово

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

Скільки часу дати учасникам

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

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

Крок 5. Оцінка і короткий список

Оцініть пропозиції за критеріями з вагами. Двоє-троє оцінювачів з різних підрозділів (бізнес, IT, безпека) дають збалансованіший результат: бізнес бачить розуміння задачі, IT бачить якість підходу, безпека бачить ризики з даними. До короткого списку увійдуть два-три учасники.

Крок 6. Перевірка фіналістів

Для фіналістів:

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

Окремо про тендери на рішення з ШІ

Для AI-агентів і систем на основі моделей мови порівняння пропозицій на папері працює гірше, бо якість відповідей залежить від ваших даних. Додайте до тендеру три елементи.

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

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

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

Оцінювальна таблиця

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

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

Крок 7. Договір

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

Типові помилки тендерів на розробку

Одна сума замість кошторису. Порівнювати нема чого.

Критерії після подання. Учасники не знають, що важливо, і оптимізують ціну.

Питання телефоном. Хтось дізнається більше за інших, і умови перестають бути рівними. Письмовий канал для питань захищає і вас: усе, що ви пояснили учасникам, зафіксоване.

Задача, описана одним реченням. Пропозиції різняться в рази, бо кожен уявив свій продукт. Детальніше про причини у статті чому оцінки розробки різняться в рази.

Ігнорування супроводу. Продукт після запуску потребує догляду, і вартість супроводу за кілька років може бути порівнянна з розробкою. Попросіть учасників описати формат супроводу і приклад місячного звіту, як у статті що входить у підтримку після запуску.

Для державних і комунальних замовників

Для замовників, що працюють за законом про публічні закупівлі, процедура визначається законодавством і проходить через Prozorro. Принципи з цієї статті (опис задачі, форма кошторису, критерії) стосуються змісту тендерної документації, а порядок процедури визначає закон і ваш юрист.

Як ми відповідаємо на тендери

Коли Initask отримує запит пропозицій, ми заповнюємо форму кошторису рядками з годинами нетто і окремо перелічуємо, що в пропозицію не входить. Якщо у вас ще немає форми або запиту, надішліть опис задачі у формі: оцінка після брифу займає робочий день і приходить у вигляді, який зручно порівнювати з іншими пропозиціями. Формат робіт описаний на сторінках розробка програмного забезпечення, розробка веб-застосунків і впровадження ШІ. Перелік перевірок підрядника зібраний у статті як обрати підрядника на розробку.