Тендер Закупівля комплексу обладнання для побудови центру обробки даних, закупівля від БЮРО ЕКОНОМІЧНОЇ БЕЗПЕКИ УКРАЇНИ, номер UA-2025-06-27-008235-a в системі Prozorro

Опис суті пункту скарги

Ознайомившись із закупівлею постало питання правильності вибору класифікатора ДК 021:2015: 32420000-3 — Мережеве обладнання - пункт 4.1. Розділ 1. Загальні положення. Згідно з даними в оприлюдненій тендерній документації в Додатку 5 до тендерної документації "ІНФОРМАЦІЯ ПРО НЕОБХІДНІ ТЕХНІЧНІ, ЯКІСНІ ТА КІЛЬКІСНІ ХАРАКТЕРИСТИКИ ПРЕДМЕТА ЗАКУПІВЛІ, У ТОМУ ЧИСЛІ ВІДПОВІДНА ТЕХНІЧНА СПЕЦИФІКАЦІЯ", предмет закупівлі включає: серверне обладнання (сервери, системи зберігання, контролери), ліцензійне програмне забезпечення (наприклад, ОС, віртуалізація, резервне копіювання тощо), послуги з встановлення, конфігурації та пусконаладки. Відповідно до Класифікатора ДК 021:2015 даній закупівлі обгрунтовано відповідає код ДК 30210000-4 – Машини для обробки даних (апаратна частина), який охоплює сервери, сховища, апаратні комплекси, а також дозволяє включати супутні послуги та ПЗ як частину постачання, що є предметом закупівлі UA-2025-06-27-008235-a. Даний факт вибору неправильного коду ДК класифікатору ДК 021:2015 є вагомою підставою для контролюючих органів визнати договір нікчемним. Підстави, за яких договір про закупівлю є нікчемним визначені пунктом 21 Особливостей, зокрема у разі, коли назва предмета закупівлі із зазначенням коду за Єдиним закупівельним словником не відповідає товарам, роботам чи послугам, що фактично закуплені замовником. Зауважимо, що згідно з пунктом 3 Порядку визначення предмета закупівлі, затвердженого Наказом Мінекономіки 15 квітня 2020 року № 708 предмет закупівлі товарів і послуг визначається замовником згідно з пунктами 21 і 34 частини першої статті 1 Закону та за показником четвертої цифри Єдиного закупівельного словника. Крім того, звертаємо увагу, що згідно з частиною другою статті 215 Цивільного кодексу України недійсним є правочин, якщо його недійсність встановлена законом (нікчемний правочин). У цьому разі визнання такого правочину недійсним судом не вимагається. Для наочності проблеми та можливих наслідків наводимо існуючу практику недавніх висновків моніторингу, де органами контролю було встановлено порушення в частині неправильного визначення предмета закупівлі за Єдиним закупівельним словником. Закупівля: Трактор колісний з навісним обладнанням / UA-2024-07-12-006518-a (зобов’язання: припинити зобов’язання за договором про закупівлю, в тому числі із застосуванням відповідних наслідків недійсності/нікчемності договору). Висновок від 11.09.2024; Закупівля: Гречка, рис, пшоно, крупа ячнева, крупа вівсяна, крупа пшенична, борошно пшеничне в/г, крупа кукурудзяна, крупа перлова, кус-кус, крупа арнаутка / UA-2023-12-28-005652-a (зобов’язання: розірвати договір про закупівлю, в тому числі із застосуванням відповідних наслідків недійсності/нікчемності договору). Висновок від 19.06.2024; Закупівля: Капітальний ремонт дороги по вулиці Шевченка від буд. №2 до буд №8 (біля парку Здебського) в с. Розвадів Стрийського району Львівської області / UA-2023-06-06-002016-a (зобов’язання: розірвати договір, враховуючи норми договору, Закону України «Про публічні закупівлі», Цивільного та Господарського кодексів України). Висновок від 11.10.2023. Зверніть увагу, що у всіх наведених висновках, аудитори зобов’язали замовників розірвати договір через невірно обраний замовником ДК класифікатор ДК 021:2015. Просимо зобов'язати Замовника враховуючи відсутність технічної можливості виправлення даних електронних полів закупівлі а саме - дані про Класифікатор та його відповідний код відмінити закупівлю - для уникнення потенційного визнання договору нікчемним.

Докази

Назва доказу

Скарга від 1.07.2025

Пов'язаний документ

Скарга від 1.07.2025_.pdf

Доказ №2

Назва доказу

Скарга від 1.07.2025

Пов'язаний документ

Скарга від 1.07.2025_ (ворд).docx

Вимоги

Тип вимоги

Зобов'язати замовника відмінити процедуру закупівлі

Опис вимоги

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

Пункт скарги №2

Порядковий номер пункту скарги 2

Заголовок пункту скарги

2) Стосовно «Мережевий комутатор, тип 1 (Juniper QFX5120-48Y-AFO2), або еквівалент» (сторінка 30 Додатку 5)

Тип пов'язаного елемента

Лот

Ідентифікатор пов'язаного елемента

UA-2025-06-27-008235-a

Тип порушення

Порушення, пов'язані з вимогами законодавства

Вимога законодавства про публічні закупівлі, з яким пов’язане вчинене замовником порушення

Технічна специфікація предмета закупівлі

Суті пункту скарги

Опис суті пункту скарги

В Додатку 5 тендерної документації (сторінка 30) наявна вимога, що Операційна система комутатора має підтримувати: • Застосування перевіреної конфігурації в заздалегідь встановлений час. • Повернення на попередню працездатну конфігурацію у разі помилки адміністратора. Вимога щодо підтримки staged config з можливістю застосування перевіреної конфігурації у заздалегідь встановлений час та автоматичного повернення на попередню конфігурацію у разі помилки адміністратора є архітектурною особливістю Juniper Junos OS. Інші ОС реалізують стабільність конфігурації іншими методами (checkpoint, archive, зовнішній backup). Це штучно звужує конкуренцію, що суперечить ч. 4 ст. 5 ЗУ «Про публічні закупівлі». 1. Це пряма реалізація commit-моделі (staged config + commit confirmed + commit at time), що є фірмовою архітектурною особливістю Juniper Junos OS. 2?. У більшості інших ОС: • Cisco IOS XE / NX-OS: немає повноцінної commit-моделі з відкладеним застосуванням. Є лише archive config або configure replace. • HPE Comware, Aruba, Dell OS10: аналогічно — staged config та commit confirmed не підтримуються в нативному вигляді. 3?. Це обмежує вибір тільки до виробників, що реалізують staged config, а таких немає, окрім Juniper. https://www.juniper.net/documentation/us/en/software/junos/cli/topics/topic-map/junos-configuration-commit.html Вимагаємо видалити цю вимогу або допустити еквівалентну реалізацію rollback механізмів. Дана вимога є дискримінаційною.

Докази

Назва доказу

Скарга від 1.07.2025

Пов'язаний документ

Скарга від 1.07.2025_.pdf

Вимоги

Тип вимоги

Зобов'язати замовника внести зміни до тендерної документації

Опис вимоги

Вимагаємо видалити цю вимогу або допустити еквівалентну реалізацію rollback механізмів. Дана вимога є дискримінаційною.

Пункт скарги №3

Порядковий номер пункту скарги 3

Заголовок пункту скарги

3) Стосовно «Мережевий комутатор, тип 1 (Juniper QFX5120-48Y-AFO2), або еквівалент» (сторінка 31 Додатку 5)

Тип пов'язаного елемента

Лот

Ідентифікатор пов'язаного елемента

UA-2025-06-27-008235-a

Тип порушення

Порушення, пов'язані з вимогами законодавства

Вимога законодавства про публічні закупівлі, з яким пов’язане вчинене замовником порушення

Технічна специфікація предмета закупівлі

Суті пункту скарги

Опис суті пункту скарги

В Додатку 5 тендерної документації ( сторінка 31 ) наявна вимога, що Функціональність 2-го рівня: • Підтримка технології агрегації Ethernet каналів з балансуванням за МАС-адресою джерела/призначення, IP-адресою джерела/призначення, TCP/UDP-портами джерела/призначення, полем Ethertype, VLAN ID, вхідним інтерфейсом. Вимога щодо обов’язкової підтримки балансування LAG за полем Ethertype, VLAN ID та вхідним інтерфейсом є вузькоспецифічною для окремих рішень (Juniper). Більшість виробників (Cisco, Arista, Dell, HPE) реалізують стандартне балансування LAG на рівні L2/L3/L4 (MAC, IP, TCP/UDP), що забезпечує рівнозначну ефективність. Це звужує конкуренцію, що суперечить ч. 4 ст. 5 ЗУ «Про публічні закупівлі». 1. Балансування по MAC, IP, TCP/UDP-портам — це стандартна функція LAG/LACP у всіх сучасних комутаторах (Cisco, Dell, Arista, HPE, Juniper). 2?. Балансування по полю Ethertype та вхідному інтерфейсу — це не галузевий стандарт: • Це реалізовано у Juniper як частина специфічного hash-policy. • Cisco, Arista, Dell — не мають granular hash по Ethertype та ingress interface. Вони використовують стандартні Layer2/3/4 хеш-поля. • IEEE 802.3ad (LACP) не визначає Ethertype як обов’язковий параметр балансування. 3?. VLAN ID — теж не завжди доступний як окремий хеш-параметр у всіх вендорів, бо звичайний ASIC хешує L2/3/4 поля. https://www.juniper.net/documentation/us/en/software/junos/interfaces-ethernet/topics/concept/ethernet-link-aggregation-acx.html Вимагаємо видалити параметри «Ethertype», «VLAN ID» та «вхідний інтерфейс» або дозволити еквівалентні LAG hash алгоритми.

Докази

Назва доказу

Скарга від 1.07.2025

Пов'язаний документ

Скарга від 1.07.2025_.pdf

Вимоги

Тип вимоги

Зобов'язати замовника внести зміни до тендерної документації

Опис вимоги

Вимагаємо видалити параметри «Ethertype», «VLAN ID» та «вхідний інтерфейс» або дозволити еквівалентні LAG hash алгоритми.

Пункт скарги №4

Порядковий номер пункту скарги 4

Заголовок пункту скарги

4) Стосовно 4) «Мережевий комутатор, тип 1 (Juniper QFX5120-48Y-AFO2), або еквівалент» (сторінка 34 Додатку 5)

Тип пов'язаного елемента

Лот

Ідентифікатор пов'язаного елемента

UA-2025-06-27-008235-a

Тип порушення

Порушення, пов'язані з вимогами законодавства

Вимога законодавства про публічні закупівлі, з яким пов’язане вчинене замовником порушення

Технічна специфікація предмета закупівлі

Суті пункту скарги

Опис суті пункту скарги

В Додатку 5 тендерної документації (сторінка 34 ) наявна вимога, що Функціонал управляння має підтримувати: • Можливість написання та виконання скриптів SLAX, XSLT, Python. Вимога щодо обов’язкової підтримки скриптів SLAX та XSLT є специфічною для архітектури Juniper Junos OS і не реалізується іншими виробниками (Cisco, Dell, Arista, HPE). Більшість сучасних рішень підтримують Python або API-інтеграції. Це звужує конкуренцію, що суперечить ч. 4 ст. 5 ЗУ «Про публічні закупівлі». SLAX і XSLT — це специфічні мови для обробки XML конфігурацій у Juniper Junos OS. • Це фірмовий підхід до автоматизації конфігурацій у Junos. • Інші виробники таку архітектуру не використовують: Cisco IOS XE, NX-OS — підтримують тільки EEM, TCL або Python. Dell OS10, Arista EOS — Python, bash або API. HPE Comware/Aruba — аналогічно: Python, Ansible, REST API. SLAX і XSLT — унікальні для Juniper. https://www.juniper.net/documentation/product/us/en/junos-snapshot-administrator-slax/ https://www.juniper.net/documentation/us/en/software/junos/automation-scripting/topics/concept/junos-script-automation-xslt-overview.html Вимагаємо видалити «SLAX» та «XSLT», залишивши Python або еквівалентні механізми автоматизації.

Докази

Назва доказу

Скарга від 1.07.2025

Пов'язаний документ

Скарга від 1.07.2025_.pdf

Вимоги

Тип вимоги

Зобов'язати замовника внести зміни до тендерної документації

Опис вимоги

Вимагаємо видалити «SLAX» та «XSLT», залишивши Python або еквівалентні механізми автоматизації.

Пункт скарги №5

Порядковий номер пункту скарги 5

Заголовок пункту скарги

5) Стосовно «Мережевий комутатор, тип 2 та тип 3 (Juniper EX4100-48T та Juniper EX4100-48P), або еквівалент» (сторінка 36 Додатку 5)

Тип пов'язаного елемента

Лот

Ідентифікатор пов'язаного елемента

UA-2025-06-27-008235-a

Тип порушення

Порушення, пов'язані з вимогами законодавства

Вимога законодавства про публічні закупівлі, з яким пов’язане вчинене замовником порушення

Технічна специфікація предмета закупівлі

Суті пункту скарги

Опис суті пункту скарги

В Додатку 5 тендерної документації (сторінка 36) наявна вимога, що Операційна система: • Пакетне застосування команд конфігурації (commit модель). • Можливість застосування нової конфігурації у заданий момент часу. • Можливість відкату на попередню конфігурацію (rollback). • Можливість автоматичного відкату на попередню конфігурацію через заданий інтервал часу. Вимоги щодо підтримки commit-моделі, відкладеного застосування конфігурації у заданий час, rollback та автоматичного rollback через commit confirmed є специфічною архітектурною особливістю Juniper Junos OS. Інші ОС (Cisco, Dell, Arista, HPE) реалізують аналогічну стабільність конфігурацій через checkpoint, archive, configure replace або зовнішній конфіг-менеджмент. Це звужує конкуренцію, що суперечить ч. 4 ст. 5 ЗУ «Про публічні закупівлі». 1. Повноцінна commit-модель у вигляді staged candidate config + timed commit + commit confirmed — це архітектурна особливість Juniper Junos OS. 2?. Інші ОС (Cisco IOS XE, NX-OS, Dell OS10, Aruba AOS-CX, HPE Comware): • Використовують інший підхід — конфігурація застосовується по мірі введення команд, немає окремого commit. • Rollback реалізується через checkpoint, archive config або configure replace. • Відкладене застосування конфігурації (scheduled commit) нативно відсутнє — це робиться через зовнішній скрипт/автоматизацію. Ця вимога прив’язує до єдиного виробника, що прямо обмежує ринок. Більшість виробників пропонують: Checkpoint. • Archive конфігурацій. • Ручний або скриптовий rollback. • Зовнішній конфіг-менеджмент (Ansible, GitOps, Python EEM). Це дозволяє досягти того ж рівня стабільності. https://www.juniper.net/documentation/us/en/software/junos/cli/topics/topic-map/junos-configuration-commit.html . Вимагаємо видалити ці вимоги або передбачити еквівалентну реалізацію через інші механізми.

Докази

Назва доказу

Скарга від 1.07.2025

Пов'язаний документ

Скарга від 1.07.2025_.pdf

Доказ №2

Назва доказу

Скарга від 1.07.2025

Пов'язаний документ

Скарга від 1.07.2025_ (ворд).docx

Доказ №3

Назва доказу

Скарга від 1.07.2025

Пов'язаний документ

Скарга від 1.07.2025_ (ворд).docx

Вимоги

Тип вимоги

Зобов'язати замовника внести зміни до тендерної документації

Опис вимоги

Вимагаємо видалити ці вимоги або передбачити еквівалентну реалізацію через інші механізми.

Пункт скарги №6

Порядковий номер пункту скарги 6

Заголовок пункту скарги

6) Стосовно «Мережевий комутатор, тип 2 та тип 3 (Juniper EX4100-48T та Juniper EX4100-48P), або еквівалент» (сторінка 41 Додатку 5)

Тип пов'язаного елемента

Лот

Ідентифікатор пов'язаного елемента

UA-2025-06-27-008235-a

Тип порушення

Порушення, пов'язані з вимогами законодавства

Вимога законодавства про публічні закупівлі, з яким пов’язане вчинене замовником порушення

Технічна специфікація предмета закупівлі

Суті пункту скарги

Опис суті пункту скарги

В Додатку 5 тендерної документації (сторінка 41) наявна вимога, що Вимоги до функціональності 2-го рівня комутації: • Обмеження кількості MAC адрес на даному VLAN. Вимога щодо обмеження кількості MAC-адрес на рівні VLAN є специфічною для Carrier Ethernet/Metro Ethernet класу. Більшість виробників (Cisco, Dell, Arista, HPE) реалізують MAC limiting через Port Security на портах, що дозволяє досягти того ж ефекту. Це звужує конкуренцію, що суперечить ч. 4 ст. 5 ЗУ «Про публічні закупівлі». Глобальний MAC limit на VLAN — не є ринковим стандартом для L2-комутаторів Access/Leaf. • Вимога глобального VLAN limit штучно прив’язує до Metro Ethernet або Carrier Ethernet фіч, які є у вузького переліку платформ (наприклад, Juniper EX з PE-функціями). • Більшість Access/Leaf комутаторів такої функції не мають — тому це звужує вибір, суперечить принципу рівної участі. https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/mac-limit-edit-vlans-qfx-series.html Вимагаємо видалити цю вимогу або дозволити еквівалентну реалізацію обмеження MAC-адрес на портах.

Докази

Назва доказу

Скарга від 1.07.2025

Пов'язаний документ

Скарга від 1.07.2025_.pdf

Доказ №2

Назва доказу

Скарга від 1.07.2025

Пов'язаний документ

Скарга від 1.07.2025_ (ворд).docx

Вимоги