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

Опубліковано: 2026-09-16 Джерело: 许愿牛科技

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

Коли підприємства купують програмне забезпечення або цифрові та інтелектуальні послуги, у тендерних документах досі часто зустрічається вимога: «Учасник тендеру повинен мати XX старших інженерів та забезпечити присутність на місці не менш ніж XX людино-місяців». У таблицях оцінювання оцінки розподіляються за кількістю осіб, кваліфікацією та ціною за одиницю — такий підхід був обґрунтованим ще десять років тому, але…Інтелектуальний агент та допоміжна доставка на основі ШІУ сучасному світі часто вибирають постачальника, який має найбільшу кількість людей, а не того, чий результат найбільш чіткий.

Комітет з закупівель оцінює пропозиції постачальників програмного забезпечення

Політичний контекст: логіка закупівель змінюється

У вересні 2026 року Міністерство промисловості та інформаційних технологій опублікувало «План реалізації спеціальної програми „Штучний інтелект + програмне забезпечення“», у якому запропоновано сприяти інтелектуалізації програмного забезпечення, розвитку моделей «інтелектуальний агент як послуга» тощо, а також наголошено на тому, щоНе дивлячись на обсяг інвестицій, а на те, які результати досягнуті.. Для замовника сигнал дуже чіткий: якщо продовжувати орієнтуватися лише на люднодень та кількість працівників на місці, можна отримати «бурхливу реалізацію», але не досягти перевіреної бізнес-оптимізації.

Оцінка пропозицій за критеріями та оцінка результатів: у чому різниця

ВимірТрадиційна оцінка тендерів за людино-днями/людино-головамиОцінка на основі результатів
Основні показникиКількість людей, рівень, кількість днів перебування на місці, ціна за одиницюЗамкнуте кільце сценарію, скрипт приймання, KPI після запуску в роботу
Висловлення потребиВибір у списку функційРобочі дії + методи обрахунку даних + правила винятків
Обробка змінНа місці обговорюється додавання людей та збільшення бюджетуЯкі важливі моменти та які KPI впливають на зміни?
ШІ/інтелектуальний агентЗазвичай не включається до оцінкиНеобхідно вказати точки підвищення ефективності, пункти ручної перевірки та межі прав доступу.
Вузол оплатиРозрахунок за квартал або за людино-місяціОплата за прийняття робіт згідно з етапами завершення проекту
Ключовий момент суперечки«Чи достатньо людей»«Чи пройшов сценарій, чи покращилися показники»

Логіка бізнесу: як змінити тендерну документацію

Замініть документацію з закупівель із «купувати руки» на «купувати результат», рекомендуємо переписати чотири блоки:

  1. Список сценаріїв: Пишіть «поточна ситуація та проблеми → цільові дії» відповідно до посади, наприклад: «Замовник перейшов із оформлення замовлення через електронну пошту до закритого процесу затвердження PO у системі».
  2. Сценарій приймання: До кожного сценарію додаються кроки тестування, вхідні дані та очікувані результати; пропозиція тендерної сторони має містити пояснення реалізованості кожного пункту.
  3. Обіцянка KPI: Упродовж 90 днів після запуску можна виміряти такі показники, як частка скорочення терміну затвердження, рівень розбіжності при звірці та точність складського обліку — показники повинні бути доступними для системного збору даних.
  4. Межа послуги: Навчання, експлуатація та технічне обслуговування, міграція даних, підтримка правил інтелектуального агента — кожен з цих напрямків має чітко визначену відповідальність, щоб уникнути ситуації, коли «після запуску все закінчується».

Рекомендації щодо ваги оцінки:Відповідність рішення та приймання – 40% + практична ефективність подібних випадків – 30% + ціна – 20% + компетентність команди – 10%. Команда все ще має бути наочна, але не повинна домінувати, інакше знову повернемося до переповнення штату.

Логіка проектування: як інтелектуальні агенти та автоматизація впливають на оцінювання тендерів

Якщо вартість пропозиції включає розумного клієнтського сервісу, автоматичне нагадування та двигун правил, замовник має попросити учасника торгів надати відповідь:

  • Введення та виведення: які документи читати, які статуси записувати, чи можна проводити аудит.
  • Права та оновлення: Які операції обов’язково потребують підтвердження вручну, і яким чином проводиться їхнє подальше розгляд у разі перевищення терміну.
  • Точність та вибіркова перевірка: Як вимірювати базову лінію зобов’язань та як відкотити помилкові дії.
  • Залежність від постачальника: Чи можна експортувати моделі, правила та базу знань, щоб уникнути повного зупинення після переходу до іншого заводу.

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

Впровадження та приймання: третя фаза контролю доступу

Рекомендується чітко вказати у контракті три етапи контролю доступу та прив'язати оплату до приймання:

  1. Перший етап (4–8 тижнів): Основний сценарій виконано на 100%, навчання ключових фігур завершено. Якщо не пройдено — друга частина оплати не сплачується.
  2. Друга фаза (8–12 тижнів): Забезпечено інтеграцію міжвідомчих процесів, стабільність інтерфейсів та основних даних, а також запущений збір базових даних KPI.
  3. Третя фаза (90 днів операційної діяльності): Проводиться аналіз виконання KPI за контрактом; у разі недотримання передбачені періоди для виправлення та штрафні санкції, а не безстрокове присутнє на місці робочого процесу.

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

Поширені помилки покупців

Помилка перша: виграння тендеру за низькою ціною за людино-дні——У подальшому внесенні змін ціна зростає, а загальні витрати стають більшими. Рішення: обмеження загальної ціни + таблиця розрахунку змін.

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

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

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

Наступний крок

Якщо ви знову плануєте запускати проекти з ERP, OA, SRM або індивідуального цифрового розвитку, спочатку витратьте один тиждень на «медичний огляд тендеру»: позначте всі пункти у поточному RFP червоним кольором і поступово перепишіть кожен пункт у форматі сценарій + скрипт + KPI. Навіть якщо не встигнете завершити — це не проблема; принаймні наступна версія тендеру вже не буде обирати постачальників за логікою 2015 року.

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

Додаткові моменти, на які слід звернути увагу при закупівлі державними підприємствами та групами

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

Під час демонстраційної частини комітету з закупівель рекомендується на місці вибрати 2–3 сценарії, які будуть реалізовані сторонами-претендентами, а члени журі оцінюватимуть результати відповідно до очікуваних показників — це набагато більш приближено до реального досвіду після запуску системи, ніж просто перегляд презентацій. На етапі переговорів щодо контракту варто включити у основний текст положення про «період коригування та формулу зменшення оплати у разі недотримання KPI» — такий підхід краще захищає обидві сторони, ніж подальші домовленості через особисті зв’язки. Реформа процесу оцінки пропозицій не потребує очікування виходу наступної версії національного стандарту: вже при наступній закупівлі можна спробувати один сценарій, один KPI та одну фазу контролю доступу. Постійне поступове тестування з можливістю помилок допоможе швидше адаптуватися до змін як політики, так і технологій, ніж чекати на ідеальний шаблон.