Українські продуктові IT-компанії створюють конкурентоспроможне програмне забезпечення, здатне вирішувати найскладніші завдання національного масштабу. Проте на ринку публічних закупівель вітчизняні розробники часто стикаються з дискримінаційними вимогами у тендерній документації. Ці нетехнічні бар’єри штучно обмежують доступ українського інтелектуального капіталу (IP) до державних контрактів на користь застарілих іноземних рішень. Для власників та CEO продуктових компаній це стратегічний виклик, який безпосередньо впливає на капіталізацію бізнесу та можливість масштабування на локальному ринку.
Анатомія дискримінації: як нетехнічні бар'єри блокують український софт
Закупівля програмного забезпечення в Україні регулюється встановленим порядком, який визначає правила вибору постачальників і має забезпечувати прозору конкуренцію. Однак на практиці державні замовники часто закладають у вимоги нетехнічні бар'єри. Найбільш поширеними є умови щодо наявності специфічних партнерських сертифікатів конкретного іноземного вендора або підтвердженого досвіду впровадження саме його ліцензійних продуктів.
Для українського продуктового бізнесу це створює дилему: інвестувати значні ресурси у проходження іноземних сертифікацій, які не мають прямого відношення до якості власного коду, або ініціювати через профільні ІТ-асоціації перегляд критеріїв. Вибір другого шляху дозволяє захистити власне IP та перевести фокус закупівель на об'єктивні функціональні вимоги та відкриті стандарти безпеки.
Моноліт проти мікросервісів: чому застарілі архітектурні вимоги консервують неефективність
Технічні завдання у державних тендерах часто жорстко фіксують монолітну архітектуру, унеможливлюючи участь сучасних cloud-native рішень. Згідно з визначенням Мартіна Фаулера, мікросервісний стиль розробки передбачає побудову систем з незалежно розгортуваних сервісів, що забезпечує гнучкість управління та швидкість доставки нових функцій.
Варто зазначити, що мікросервіси не є універсальним рішенням для будь-якого проєкту. На початкових етапах розробки (monolith-first підхід) моноліт може бути економічно доцільнішим через простішу інфраструктуру. Проте коли замовник купує масштабну національну систему і штучно вимагає виключно застарілу монолітну модель, це консервує технологічну відсталість. Сучасні підходи дозволяють значно знизити витрати на масштабування порівняно з традиційними legacy-системами.
Прихована ціна legacy: чому ігнорування TCO шкодить бюджету
Поширеною помилкою при оцінці пропозицій у тендерах є орієнтація виключно на первинну вартість ліцензій, ігноруючи сукупну вартість володіння (TCO — Total Cost of Ownership). Legacy-системи можуть здаватися дешевшими на етапі стартової закупівлі, але їхня підтримка та кастомізація вимагають великих бюджетів.
За даними аналітичних звітів у сфері ІТ-консалтингу, у застарілих системах до 49% витрат припадає на підтримку працездатності legacy-коду, тоді як на розвиток та впровадження нових функцій залишається лише близько 13% бюджету. Відсутність критеріїв оцінки TCO на горизонті 3–5 років дозволяє приховувати ці витрати та блокує конкуренцію з боку економічно ефективніших українських платформ.
Стандарти замість брендів: принципи 12-Factor App та відкритий код
Замість прив'язки до брендів, тендерна документація має орієнтуватися на сучасні методології розробки. Зокрема, дотримання принципів 12-Factor App забезпечує портативність програмного забезпечення між різними середовищами та суттєво спрощує горизонтальне масштабування.
Опис вимог навколо відкритих інтерфейсів (API), інтеграційних протоколів та стандартів сумісності створює рівні умови для учасників. Це дозволяє вітчизняним компаніям конкурувати за рахунок якості архітектури, а не партнерських статусів від глобальних корпорацій.
Формула справедливого тендеру: як масштабувати українське IP
Для створення високонавантажених систем публічному сектору не обов'язково обирати іноземні пропрієтарні рішення, адже в Україні існує зріла технологічна база. Прикладом такої основи є full-stack JavaScript low-code / model-driven платформа UnityBase. Це спільна розробка компаній Intecracy Group (ключовим, але не єдиним розробником якої є InBase). Платформа надає архітектурні механізми для enterprise-застосунків: єдину доменну модель (Domain metadata), автоматично згенерований REST API, гнучкі моделі розмежування доступу (RBAC/RLS) та вбудовані інструменти аудиту (audit trail).
На базі UnityBase побудовані такі рішення, як системи електронного документообігу Megapolis.DocNet та Scriptum, що підтверджує здатність українського ПЗ працювати в умовах високих навантажень та суворих вимог безпеки. Додатковою перевагою відкритої архітектури є можливість інтеграції сучасних AI-рішень — наприклад, сервісів комп'ютерного зору чи аналітики від компанії Softengi, яка сертифікована за міжнародним стандартом управління штучним інтелектом ISO/IEC 42001.
Для захисту інтересів держави та розвитку українського ІТ-ринку критеріями вибору в державних закупівлях мають стати відкрита архітектура, реальна безпека та підтверджена економічна ефективність, розрахована через TCO.
| Дискримінаційна вимога | Обґрунтування обмеження | Сучасна відкрита альтернатива |
|---|---|---|
| Наявність специфічних партнерських сертифікатів іноземного вендора | Штучно звужує коло учасників до партнерів одного бренду | Вимога відповідності відкритим стандартам безпеки та інтеграційної сумісності |
| Жорстка прив'язка до монолітної архітектури конкретної legacy-системи | Унеможливлює використання гнучких мікросервісних та cloud-native рішень | Опис вимог до API, інтеграційних протоколів та методів горизонтального масштабування |
| Оцінка пропозиції виключно за первинною ціною ліцензій | Приховує великі витрати на подальше обслуговування та кастомізацію | Обов'язкова оцінка сукупної вартості володіння (TCO) на горизонті 3–5 років |
Поширені питання
Як українській продуктовій компанії оскаржити дискримінаційні вимоги в тендерній документації?
Компанія може подати офіційну вимогу замовнику через електронну систему закупівель із детальним технічним обґрунтуванням того, як конкретні вимоги обмежують конкуренцію. У разі відхилення вимоги учасник має право подати скаргу до Антимонопольного комітету України (АМКУ), надавши докази, що технічне завдання прописане під конкретний продукт іноземного виробника.
Які архітектурні вимоги в ТЗ свідчать про приховану закупівлю під конкретного іноземного вендора?
Ознаками є використання специфічних назв внутрішніх модулів, жорстка вимога щодо використання пропрієтарної бази даних або закритої інтеграційної шини конкретного бренду, а також відсутність опису відкритих інтерфейсів (API) замість яких деталізуються унікальні технічні особливості однієї системи.
Як довести замовнику перевагу cloud-native архітектури над застарілими монолітними системами під час тендеру?
Аргументація має будуватися на фінансовій та експлуатаційній ефективності: варто надати розрахунок TCO, що демонструє менші витрати на масштабування, та послатися на принципи 12-Factor App, які забезпечують незалежність ПЗ від конкретного хмарного середовища та відмовостійкість при пікових навантаженнях.
Джерела даних
- vertexaisearch.cloud.google.com: Закупівля програмного забезпечення - Держзакупівлі
- martinfowler.com: Microservices — a definition (Fowler & Lewis)
- Heroku / community: The Twelve-Factor App
- vertexaisearch.cloud.google.com: Перелік забороненого програмного забезпечення - Радник у сфері публічних закупівель