Закупівля ПЗ на замовлення: посібник замовника на 2026 рік у 7 кроках
Закупівля програмного забезпечення (ПЗ) на замовлення означає процес замовлення індивідуального ПЗ у зовнішнього вендора-розробника: бізнес-кейс, опис обсягу робіт, RFP, оцінка вендора, договір і приймальне випробування, яке ставить крапку. Це не продукт. Це процес закупівлі, який проводите ви.
Введіть запит у Google, і ви отримаєте дев'ять каталогів інструментів та одну сторінку політики UCLA на 900 слів. Сам процес ніхто не розкриває, бо контент, який потрапляє в топ, пишуть вендори інструментів. Цей посібник відповідає на друге запитання: як купити ПЗ, якого ще не існує?
Ключові висновки:
- Закупівля ПЗ на замовлення це процес замовлення індивідуального ПЗ у вендора, а не покупка інструменту для закупівель.
- Повний цикл закупівлі це 7 кроків від бізнес-кейсу до підписаного приймання, зазвичай 10–16 тижнів до початку розробки.
- Дев'ять пунктів договору захищають ваш бюджет; найсильніше діють право власності на ІВ, критерії приймання та платежі за контрольними точками.
Закупівля ПЗ на замовлення це не софт для закупівель
Софт для закупівель це інструмент, який автоматизує покупки: замовлення, погодження, виставлення рахунків, каталоги постачальників. Закупівля ПЗ на замовлення це процес замовлення індивідуального ПЗ у вендора-розробника. Перше це продукт, на який ви купуєте ліцензію. Друге це проєкт, який ви ведете: з договором і приймальним випробуванням. Цей посібник про друге.
Плутанина зрозуміла: ринок інструментів величезний і добре висвітлений. Каталог провайдерів Art of Procurement містить понад 200 платформ у 19 категоріях, а путівник із закупівель Brex на 2026 рік на майже 4 000 слів порівнює п'ять із них. Ніхто з них не пояснює, як замовити ПЗ з нуля. Саме цю прогалину закриває ця стаття.
Перед стартом: чи справді кастомне ПЗ це правильна покупка?
Кастомне ПЗ варто купувати, коли програмне забезпечення є ядром ваших операцій і жоден готовий продукт не вписується у робочий процес без милиць. Це зайва покупка, якщо ліцензований продукт уже покриває 80% потреби. Вирішіть чесно, перш ніж витратити хоч одну гривню на RFP для закупівлі ПЗ на замовлення.
| Варіант | Виграє, коли | На що зважати |
|---|---|---|
| Коробковий SaaS | Потреба типова (зарплата, CRM, рахунки), і 80% покриття достатньо | Плата за кожного користувача накопичується; ви орендуєте й ніколи не володієте |
| Кастомізація платформи | Платформа здебільшого підходить, а ваш нестандартний випадок це налаштування, а не перебудова | Борг кастомізації; оновлення ламають ваші доробки |
| Повна розробка на замовлення | ПЗ це ваш процес, конкуренти не можуть його купити, і вам потрібні права на ІВ | Ризик розробки несете ви, тож договір має його розподілити |
Досі не впевнені, який рядок ваш? Наша система оцінки «розробляти чи купувати» відповідає на питання «розробляти чи купувати»; цей посібник відповідає на наступне: як провести закупівлю, коли рішення ухвалено.
Потім запишіть бізнес-кейс. Достатньо однострінкового шаблону обґрунтування покупки ПЗ:
Problem: What is broken, in one sentence
Current cost: What it costs today (hours per week x rate, or lost revenue)
Outcome: The measurable result the software must produce
Ceiling: The maximum budget, and the date the money runs outНавіть закупівля силами двох людей виграє від письмової політики закупівель: один абзац про те, хто погоджує витрати та хто підписує. Це запобігає хаосу «засновник погодив у телефонній розмові», який топить приймання.
Процес закупівлі ПЗ на замовлення у 7 кроках
Процес закупівлі ПЗ на замовлення має сім кроків, і шість із них відбуваються до того, як хтось напише рядок коду. Увесь цикл, по одному рядку на крок:
- Потреба та бізнес-кейс: доведіть, що проблема варта грошей
- Опис обсягу робіт (SOW): запишіть точно, що означає «готово»
- Аналіз ринку: шорт-лист вендорів, які роблять таку роботу
- RFP / RFQ: надішліть однаковий бриф усім
- Оцінка вендора: оцінюйте відповіді за доказами, а не за відчуттями
- Переговори та договір: зафіксуйте дев'ять пунктів письмово
- Доставка та приймання: протестуйте проти критеріїв із кроку 2
Ці діапазони це наша інтерпретація типових угод із МСБ, а не виміряний бенчмарк: продовження з єдиним постачальником триває три тижні, регульований тендер пів року.
| Етап | Типові тижні | Документ на виході | Хто відповідає |
|---|---|---|---|
| 1. Потреба та бізнес-кейс | 1–2 | Однострінкове обґрунтування | Ви (замовник) |
| 2. Опис обсягу робіт | 2–4 | SOW плюс критерії приймання | Ви за участю вендора |
| 3. Аналіз ринку | 1–2 | Шорт-лист із 5–8 вендорів | Ви |
| 4. RFP / RFQ | 2–3 | Надісланий бриф і відповіді | Ви, потім вендори |
| 5. Оцінка вендора | 1–2 | Заповнена оцінна картка | Ви |
| 6. Переговори та договір | 2–3 | Підписаний договір | Обидві сторони плюс юристи |
| 7. Доставка та приймання | триває всю розробку | Підписане приймання | Обидві сторони |
| Разом до розробки | 10–16 | Підписаний договір і тестопридатний SOW | Ви |
1. Потреба та бізнес-кейс
Почніть з однострінкового документа вище. У нашій практиці проєкти, які його пропускають, змінюють обсяг посеред розробки, коли зміни коштують реальних грошей, а не одного абзацу. Він також задає стелю бюджету, яку ви вказуєте в RFP.
2. Опис обсягу робіт (SOW)
Опис обсягу робіт перетворює бізнес-кейс на специфікацію, про яку обидві сторони можуть сперечатися: функції в обсязі та поза ним, інтеграції, терміни та критерії приймання, за якими тестуватиметься результат. Як визначити обсяг проєкту веб-застосунку тут окупає себе, або визначте обсяг вимог за допомогою ШІ для швидшої чернетки.
3. Аналіз ринку
Складіть шорт-лист із п'яти-восьми вендорів зі свіжими рекомендаціями у вашій доменній сфері. Розпитайте колег, які вже запускали подібну роботу; дивіться кейси вашої галузі, а не головні сторінки. Оминайте каталоги, де рейтинг визначає реферальна комісія.
4. RFP / RFQ
Надішліть кожному вендору зі шорт-листа однаковий бриф і вимагайте однаковий формат відповіді. RFP (запит пропозицій) питає, як вони це побудують; RFQ (запит котирувань) питає, скільки коштує визначений обсяг. Для закупівлі ПЗ на замовлення першою йде RFP.
5. Оцінка вендора
Оцінюйте кожну відповідь за однаковою оцінною карткою, де рекомендації та право аудиту коду важать більше за ціну. Найдешевша пропозиція зазвичай та, яка оцінила найменший обсяг робіт. Телефонуйте за рекомендаціями самостійно.
6. Переговори та договір
Візьміть пропозицію-переможця та прикрутіть до неї дев'ять пунктів нижче. Спершу домовляйтеся про критерії приймання та платежі за контрольними точками, про ціну в останню чергу: ціну зсунути найлегше, а приймання це те, за що варто боротися.
7. Доставка та приймання
Доставка це не «вони надіслали код». Приймання означає, що ПЗ проходить критерії SOW у вашому середовищі, угоду про передачу прав на ІВ підписано, а вихідний код передано. Утримуйте останній платіж контрольної точки, доки цей тест не пройдено.
RFP, яка приносить реальні котирування
RFP без критеріїв приймання це котирування на роботу, яку ніхто не визначив. Каркас нижче це шаблон закупівлі ПЗ на замовлення, який ми хотіли б отримувати від кожного замовника. Скопіюйте його, заповніть пропуски, і п'ять вендорів оцінять один обсяг, а не вигадуватимуть п'ять різних.
CUSTOM SOFTWARE RFP
1. Company context
Who you are, team size, the system this replaces or connects to
2. Problem statement
The broken process, what it costs you today, who feels it
3. Scope
In: the features and integrations the first release must ship
Out: anything you have decided to defer
4. Technical constraints
Stack preferences, hosting rules, compliance (GDPR, HIPAA), SSO
5. Timeline
Hard dates, and what happens if you miss them
6. Budget range
A ceiling, not a target. Vendors price to the number you give.
7. Acceptance criteria
The pass/fail tests the final delivery must clear before sign-off
8. Evaluation criteria
How you will score responses, and the weight of price vs. references
9. Response format
Page limits, the questions to answer, and the reply deadlineВключіть понад усе три речі: стелю бюджету, критерії приймання, формат відповіді. Саме вони перетворюють розмиті презентації на порівнянні котирування.
Викиньте три речі: приписи щодо реалізації («використовуйте мікросервіси»), NDA до шорт-листа, 40-сторінкові додатки з вимогами. Ви купуєте результат, а не архітектуру.
Дві практичні поради: надсилайте всім вендорам однаковий документ, бо однакові відповіді це єдиний спосіб надати оцінній картці сенсу; і вкажіть ваги оцінювання в самому RFP. Вендори готують сильніші пропозиції, коли знають, що рекомендації важать більше за ціну.
Як оцінити вендора кастомного ПЗ?
Оцінка вендора означає, що кожна пропозиція проходить ту саму оцінну картку з вагами на доказах, тож рішення витримує повторний розгляд. Ціна заслуговує меншої ваги, ніж більшість замовників їй дає: пропозиції, які демпінгують, зазвичай оцінили найменший обсяг робіт. Оцінна картка, яку ми рекомендуємо для бюджетів МСБ:
| Критерій | Вага | Як оцінювати |
|---|---|---|
| Рекомендації у вашому домені | 25% | 5: дві рекомендації у вашій сфері, яким ви справді подзвонили. 1: стіна логотипів |
| Право аудиту коду | 15% | 5: письмова згода на незалежний код-рев'ю до фінального платежу |
| Фінансовий стан | 10% | 5: прибутковість і багаторічна історія. 1: не можуть підтвердити |
| Стан безпеки | 15% | 5: задокументований SDLC, сканування залежностей, доступ з мінімальними привілеями |
| Стабільність і стаж команди | 15% | 5: названа команда, низька плинність. 1: «укомплектуємо після підписання» |
| Регулярність комунікації | 10% | 5: письмове зобов'язання щодо щотижневого демо. 1: «ми в Slack» |
| Дисципліна ІВ | 10% | 5: чиста передача прав на службовий твір, без повторного використання власного ядра |
Ваги це відправна точка. Змінюйте їх, але зведіть до 100 і запишіть до того, як прочитаєте хоч одну пропозицію. Як ми ранжуємо компанії-розробники застосовує ту саму дисципліну; що насправді включають послуги розробки допоможе порівнювати рядки кошторису на однаковій основі.
Чек-лист комплексної перевірки при придбанні ПЗ
Пройдіть цей список по двох найкращих вендорах перед підписанням, а не по всіх п'ятьох:
- Рекомендації перевірені реальними запитаннями (що зламалося, як вони це вирішили, чи найняли б знову)
- Право аудиту коду погоджене письмово до фінального платежу контрольної точки
- Фінансовий стан підтверджено (років на ринку, прибутковість, концентрація клієнтів)
- Стан безпеки перевірено (SDLC, контроль доступу, історія інцидентів)
- Безперервність ключових людей підтверджено (команда з презентації це команда проєкту)
- Передачу прав на ІВ перевірив ваш юрист, а не їхній
9 пунктів договору, які захищають ваш бюджет
Пункт, який захищає ваш бюджет, це не ціна. Це приймальне випробування. Настанова UCLA із закупівель, єдина інституційна сторінка в топ-10 Google на цю тему, будує поради щодо кастомного ПЗ саме на цій ідеї: опис обсягу робіт, право власності на ІВ, приймальне випробування та гарантія, і лише потім ціна. Ми розширили цю класифікацію до дев'яти пунктів для комерційних замовників.
Якщо ви складаєте шаблон договору на придбання ПЗ, ці дев'ять рядків є його основою:
| № | Пункт | Чим він б'є | Приклад формулювання в один рядок |
|---|---|---|---|
| 1 | Право власності на ІВ / службовий твір | Без нього вендор зберігає авторське право та ліцензує ПЗ вам назад | «Усі результати робіт є службовими творами; після оплати замовник набуває повних прав на ІВ» |
| 2 | Критерії та процедура приймання | Єдине об'єктивне визначення «готово»; без нього суперечки стають питанням думки | «Результат вважається прийнятим лише тоді, коли всі тести з Додатка Б пройдено в середовищі замовника» |
| 3 | Платежі за контрольними точками | Тримає гроші позаду прогресу; прибирає ризик 100% передоплати | «20% на старті, потім 20% за кожну контрольну точку, 20% після фінального приймання» |
| 4 | Контроль змін | Не дає суперечкам про обсяг стати суперечками про рахунки | «Зміни обсягу потребують письмового замовлення на зміну із зазначенням впливу на ціну та терміни, підписаного обома сторонами» |
| 5 | Гарантійний період | Змушує вендора відповідати за код після передачі | «Вендор безоплатно виправляє дефекти, виявлені протягом 90 днів після приймання» |
| 6 | Захист ціни | Обмежує радіус ураження оптимістичних кошторисів | «Ставки T&M зафіксовані на 12 місяців; перевищення стелі лише з письмового повторного погодження» |
| 7 | Специфікації продуктивності | Робить із «воно повільне» порушення договору, а не скаргу | «p95 завантаження сторінки до 2 с; p99 API до 300 мс за 500 одночасних користувачів» |
| 8 | Ключовий персонал | Не дає підмінити команду: сеньйори на презентації, джуніори в розробці | «Призначених лідів не можна перевести на інший проєкт без письмової згоди замовника» |
| 9 | Припинення та ескроу вихідного коду | Ваш вихід, якщо вендор гальмує, банкрутує чи йде з проєкту | «Замовник може розірвати договір з поважної причини, повідомивши за 14 днів; код з ескроу видається в разі неплатоспроможності» |
Пропустіть хоч один, і ви фінансуєте надію. Якщо у вашого юриста є час лише на три пункти, дайте йому 1, 2 і 3.
Скільки коштує кастомне ПЗ і як структурувати оплату?
Обсяг визначає ціну, тому SOW існує до того, як будь-яке котирування матиме сенс. Опублікований орієнтир це оцінка ScienceSoft: $200 000–$400 000 і приблизно 10 місяців для кастомного ПЗ для закупівель корпоративного рівня; цифру ROI у 315% ScienceSoft приписує дослідженню Forrester Total Economic Impact.
Це їхні цифри для великих корпоративних розробок, не наші. Менші розробки для МСБ (внутрішній інструмент, клієнтський портал, мобільний застосунок) значно нижчі за цей діапазон; сприймайте наше прочитання для МСБ як інтерпретацію та зберіть три котирування, перш ніж довіряти будь-якому з них. Для поштучного орієнтира наш розбір вартості мобільних застосунків оцінює розробку за типом застосунку.
Структура оплати важить не менше за загальну суму:
| Модель | Виграє, коли | Ризик несе | Типове застосування |
|---|---|---|---|
| Фіксована ціна | Обсяг заморожений, а SOW без прогалин | Вендор (він поглинає перевитрати) | Добре визначені перші релізи |
| Час і матеріали (T&M) | Обсяг еволюціонуватиме, і ви довіряєте команді | Ви (тарифікується кожна додаткова година) | Проєкти з великою фазою дослідження або тривалі розробки |
| За контрольними точками | Будь-яка модель, якщо платежі прив'язані до прийнятих результатів | Спільно (гроші йдуть за доказами) | Більшість кастомних розробок МСБ |
| Купити, ліцензувати чи підписатися на ІВ | Ви повністю володієте кодом лише тоді, коли договір передає ІВ; ліцензування та SaaS-підписка це оренда | Прив'язка до вендора при ліцензуванні та підписці | Купуйте, коли ПЗ це ядро; підписуйтесь, коли це товар |
Наша рекомендація: типово обирайте платежі за контрольними точками на фіксованому обсязі, 20% або менше на старті, фінальний транш після приймального випробування. Фіксована ціна лише якщо ваш SOW витримує вороже читання; час і матеріали лише з вендором, з яким ви вже запускалися. Ніколи 100% наперед; ця структура знову з'явиться нижче.
Тривожні сигнали: як насправді провалюються закупівлі ПЗ на замовлення
Оплата 100% наперед не купує вам пріоритет. Вона перекладає весь ризик доставки на вас. Кожен тривожний сигнал нижче віддає вендору переговорну перевагу, яку ви вже не повернете:
- Розмитий SOW. «Зробіть нам CRM», без списку функцій. Кожен невизначений термін стає замовленням на зміну, оціненим без конкуренції.
- Без приймального тесту. «Зрозуміємо, коли побачимо.» Тоді ви нічого не побачите, бо «готово» ніхто не визначав.
- 100% передоплата. Гроші ваш єдиний важіль після підписання; витратьте все першого дня, і не залишиться нічого.
- Без контролю змін. Обсяг росте, рахунки ростуть, ніхто не підписував це зростання.
- Відсутня передача прав на ІВ. Ви заплатили за ПЗ і не помітили, як отримали його назад у ліцензію.
- Без пункту про ключових людей. Досвідчена команда, яка виграла презентацію, зникає наступного тижня після підписання.
Ми відповідаємо на RFP щодо кастомного ПЗ щокварталу з боку вендора, і два патерни повторюються настільки стабільно, що ми вважаємо їх базовим показником провалу закупівель: RFP взагалі без критеріїв приймання та графіки оплати, де більшість суми йде наперед, даючи вендору всі стимули відсунути проєкт у черзі, щойно гроші надійдуть. Наше прочитання, і це інтерпретація, а не вимірювання: найзапекліше торгуються за ціну ті замовники, які пропустили два пункти, приймання та контрольні точки, що цю ціну захищали б.
Галузеві дані вказують туди ж. The Standish Group три десятиліття відстежує результати проєктів у дослідженні CHAOS; його незмінний висновок: проблемні проєкти (понад бюджет, із запізненням або з нестачею функцій) чисельно переважають чисті успіхи, а розмиті вимоги та слабка підтримка керівництва тримаються біля вершини списку причин.
Якщо виправляєте лише одне, виправляйте критерії приймання. Це пункт, який робить усі інші пункти виконуваними.
Як Techsy підходить до закупівлі ПЗ на замовлення
Наш вхідний процес іде тими самими сімома кроками з іншого боку столу. Ми готуємо SOW і критерії приймання до того, як назвати цифру, бо котирування на розмитий бриф це те, як вендори занижують, а замовники переплачують. Розробка йде з платежами за контрольними точками, щотижневими демо та правом аудиту коду в кожному договорі. Коли приймання пройдено, ви володієте ІВ та репозиторієм, а не ліцензією.
Чесні обмеження: якщо вам потрібен ліцензований SaaS-інструмент, який автоматизує закупівлі, ми не той вибір. Це покупка продукту, а не розробка; вендор інструменту обслуговує швидше й дешевше. Ми беремо кастомну роботу там, де ПЗ це сам процес, а права на ІВ мають значення.
Якщо ваш проєкт у другій категорії, отримайте безкоштовну консультацію.
Часті запитання
Що таке закупівля програмного забезпечення?
Закупівля ПЗ це процес придбання програмного забезпечення: визначення потреби, оцінка варіантів, переговори про умови, приймання результату. Вона охоплює і ліцензовані продукти, і розробки на замовлення. Цей посібник зосереджений на другому: процес від бізнес-кейсу через RFP і договір до приймального випробування.
Які 4 типи закупівель існують?
Чотири загальноприйняті типи це прямі закупівлі (виробничі ресурси), непрямі (операційні товари та послуги), закупівля товарів і закупівля послуг. ПЗ лежить між непрямими закупівлями та послугами: ліцензований інструмент це непряма покупка; розробка на замовлення це послуга, що завершується переданим товаром.
У чому різниця між софтом для закупівель і закупівлею ПЗ на замовлення?
Софт для закупівель це інструмент, який автоматизує закупівельні процеси, як-от Tradogram чи Tipalti. Закупівля ПЗ на замовлення це процес замовлення індивідуального ПЗ у вендора-розробника. Шукаєте найкращу платформу для закупівель? Вам потрібне перше; цей посібник про друге.
Скільки триває закупівля ПЗ на замовлення?
Закладайте 10–16 тижнів від бізнес-кейсу до підписаного договору в типовій угоді з МСБ, до початку розробки; сприймайте це як інтерпретацію, а не бенчмарк. Продовження з єдиним постачальником стискається до тижнів; регульований тендер може розтягнутися понад шість місяців.
Скільки коштує кастомне ПЗ?
ScienceSoft оцінює кастомне ПЗ для закупівель корпоративного рівня у $200 000–$400 000 і приблизно 10 місяців, приписуючи цифру ROI у 315% дослідженню Forrester. Менші розробки для МСБ значно нижчі за цей діапазон. У закупівлі ПЗ на замовлення обсяг визначає ціну: RFP і SOW існують до того, як будь-яке котирування матиме сенс.
Кому належить інтелектуальна власність на кастомне ПЗ?
Тому, кого вказано в договорі. Без явного пункту про службовий твір або передачу ІВ вендор зберігає авторське право та ліцензує ПЗ вам назад. Зафіксуйте право власності письмово, прив'язавши до оплати: після фінального платежу замовник володіє всім. Прив'яжіть цю передачу до фінального траншу після приймання, а не до стартового платежу, щоб права переходили лише тоді, коли переходить саме ПЗ.
RFP чи RFQ: що потрібно мені?
RFP (запит пропозицій) питає, як вендори розв'яжуть вашу задачу; RFQ (запит котирувань) питає, скільки коштує визначений обсяг. Для кастомного ПЗ спершу надсилайте RFP: вендори мають запропонувати підхід, перш ніж ціна матиме сенс. RFQ надходить, коли SOW заморожений.
Фіксована ціна чи оплата за час і матеріали?
Фіксована ціна захищає вас, коли SOW без прогалин: вендор поглинає перевитрати. Час і матеріали підходять для проєктів із великою фазою дослідження, де обсяг еволюціонуватиме, але ризик перевитрат несете ви. Більшість замовників із МСБ виграють від платежів за контрольними точками на фіксованому обсязі, з фінальним траншем після приймального тесту.
Що має бути в описі обсягу робіт?
Опис обсягу робіт має називати функції в обсязі та поза ним, інтеграції, терміни, критерії приймання, за якими тестується результат, і контрольні точки оплати, прив'язані до кожного етапу. Якщо якоїсь умови немає в SOW, її немає в проєкті.
Про автора
Мерт Батур, співзасновник Techsy.io. Його команда запускає ШІ-агентів, системи автоматизації та голосові/SDR-конвеєри для B2B-клієнтів. Він пише про стек LLM-інструментів, який команда Techsy реально використовує у продакшені. Він також веде проєкти доставки кастомного ПЗ, на яких заснований цей посібник, від відповіді на RFP до підписаного приймання. Профіль у LinkedIn.
Висновок
Закупівля ПЗ на замовлення зводиться до документів, а не переговорів: однострінковий бізнес-кейс, SOW із критеріями приймання, каркас RFP, оцінна картка, договір із дев'яти пунктів. Підготуйте ці п'ять документів правильно, і розмова з вендором піде сама. Пройдіть сім кроків по порядку, утримуйте фінальний платіж до приймального випробування, і якщо хочете другу думку про ваш RFP, отримайте безкоштовну консультацію.