Тендер Серверне, мережеве обладнання та матеріали до нього, закупівля від Державна організація Український національний офіс інтелектуальної власності та інновацій, номер UA-2026-05-12-010741-a в системі Prozorro

Показати схожі тендери

Повернутися до списку закупівель

Закупівля Серверне, мережеве обладнання та матеріали до нього від Державна організація "Український національний офіс інтелектуальної власності та інновацій".

Очікувана вартість:

84 818 740 грн. (З ПДВ)

Вартість подання пропозиції:

4 080 грн.

Перевірити КЕП

Тип закупівлі:

Відкриті торги з особливостями

Тендер:

UA-2026-05-12-010741-a

Id Tender:

4a2ef2a9c5b74c46aa57617372f6e4e6

План:

UA-P-2026-05-12-011758-a

Статус:

Пропозиції розглянуто

Дата публікації оголошення:

12.05.2026 15:12

Остання зміна:

28.05.2026 13:45

Подання пропозицій ( Завершено )

з 12.05.2026 15:11 до 25.05.2026 17:14

Завершено

Період уточнень

з 12.05.2026 15:11

до 22.05.2026 00:00

Завершено

Період оскарження

з 12.05.2026 15:11

до 22.05.2026 00:00

Завершено

Період кваліфікації

з 26.05.2026 11:42

до 27.05.2026 15:27

Завершено

Період оскарження рішення на кваліфікації

з 27.05.2026 15:27

до 02.06.2026 00:00

Поточний період

Підписання договору

з 27.05.2026 15:27

Основні параметри

Назва предмета закупівлі:

Серверне, мережеве обладнання та матеріали до нього

Вид предмету закупівлі:

товари

Лоти

Лот № 1 Статус - активний лот закупівлі

84 818 740 грн.

Серверне, мережеве обладнання та матеріали до нього

Назва предмета закупівлі:

Серверне, мережеве обладнання та матеріали до нього

Очікувана вартість:

84 818 740 грн.

Розмір мінімального кроку пониження ціни:

2544562,2

3 %

Гарантійне забезпечення тендерної пропозиції:

Відсутнє

Аукціон

Cтарт аукціону:

26.05.2026 11:13

Закінчення аукціону:

26.05.2026 11:42

Посилання на аукціон:

Перейти

Опис предмета закупівлі:

Серверне, мережеве обладнання та матеріали до нього

Код ДК 021:2015:

30210000-4 - Машини для обробки даних (апаратна частина)

Кількість:

644

Одиниця виміру:

штуки

Адреса постачання:

01601, Україна, м. Київ, м. Київ, Дмитра Годзенко, 1

Дата постачання по:

09.12.2026 15:12

Умови оплати

Поставка товару

Тип оплати:

Аванс

Період:

20 робочі днів

Розмір оплати:

5,0 %

Порядковий номер:

Опис:

Оплата за Товар здійснюється Покупцем на умовах попередньої оплати у розмірі 5% (п’ять відсотків) від ціни Договору, протягом 20 (двадцяти) робочих днів з дати підписання цього Договору.

Поставка товару

Тип оплати:

Пiсляоплата

Період:

20 робочі днів

Розмір оплати:

95,0 %

Порядковий номер:

Опис:

Остаточний розрахунок у розмірі 95% (дев’яносто п’ять відсотків) здійснюється Покупцем протягом 20 (двадцяти) робочих днів з дати підписання видаткової накладної, за якою Товар в повному обсязі було передано (поставлено) Покупцю. Розрахунки за Договором здійснюються у національній валюті України шляхом безготівкового перерахування грошових коштів Покупцем на банківський рахунок Постачальника.

Умови поставки

Підписання договору

Тип поставки:

Одноразова поставка

Період:

180 календарні днів

Розмір поставки:

100,0 %

Порядковий номер:

Опис:

Поставка Товару здійснюється протягом 180 календарних днів з дати укладання Договору

Реєстр пропозицій

Учасник:

ТОВАРИСТВО З ОБМЕЖЕНОЮ ВІДПОВІДАЛЬНІСТЮ "АПІ Коннект"

Пропозиція:

74 579 964 грн.

Відповіді на критерії

Учасник:

ТОВАРИСТВО З ОБМЕЖЕНОЮ ВІДПОВІДАЛЬНІСТЮ "ДІДЖИТАЛ ПАРТНЕРС"

Пропозиція:

54 259 950 грн.

Відповіді на критерії

Учасник:

ТОВАРИСТВО З ОБМЕЖЕНОЮ ВІДПОВІДАЛЬНІСТЮ "БІЗНЕС КОНТІНЮІТІ СОЛЮШНЗ"

Пропозиція:

43 425 000 грн.

Відповіді на критерії

Посилання на аукціон

Cтарт аукціону: 26.05.2026 11:13

Критерії лоту

Критерії забезпечення

1. Забезпечення виконання договору про закупівлю

Має надати підтвердження по критерію: Переможець

Чого стосується критерій: Лот

Посилання на законодавство

Група вимог

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

Вимога

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

Тип даних:

Дробове число

Cтатус:

Активна

Дата створення:

12.05.2026 15:07

Значення, яке очікується:

Способи підтвердження

Спосіб підтвердження

Назва:

Банківська гарантія

Опис:

Вид забезпечення виконання договору про закупівлю – банківська гарантія. Розмір забезпечення виконання договору про закупівлю становить 5 % від вартості договору. Відповідно до частини 3 статті 27 розмір забезпечення договору про закупівлю не може перевищувати 5 відсотків вартості договору про закупівлю.

Тип:

Документ

Документи, що підтверджують кваліфікацію

Відповідь на вимогу

Значення:

5,0

Вимога

Строк дії гарантії перевищує строк дії Договору про закупівлю на

Тип даних:

Ціле число

Cтатус:

Активна

Дата створення:

12.05.2026 15:07

Значення, яке очікується:

Відповідь на вимогу

Значення:

Критерії закупівлі

Підстави для відмови в участі у процедурі закупівлі

1. Наявність не виконаних зобов'язань за раніше укладеним договором

Має надати підтвердження по критерію: Учасник

Чого стосується критерій: Тендер

Посилання на законодавство

Постанова Про затвердження особливостей здійснення публічних закупівель товарів, робіт і послуг для замовників, передбачених Законом України 'Про публічні закупівлі', на період дії правового режиму воєнного стану в Україні та протягом 90 днів з дня його припинення або скасування від 2026-03-26 Стаття 45.2 Номер 1178-2022-п

Група вимог

При відсутності не виконаних зобов'язань за раніше укладеним договором підтверджується, що

Вимога

Учасник процедури закупівлі не мав з цим самим замовником договорів достроково розірваних через невиконання (учасником) своїх зобов'язань через що було застосовано санкції у вигляді штрафів та/або відшкодування збитків

Тип даних:

Ознака

Значення, яке очікується:

Так

Cтатус:

Активна

Дата створення:

12.05.2026 15:07

Відповідь на вимогу

Значення:

Так

Група вимог

При наявності не виконаних зобов'язань за раніше укладеним договором підтверджується, що

Вимога

Учасник процедури закупівлі вжив заходів для доведення своєї надійності, а саме: сплатив або зобов?язався сплатити відповідні зобов?язання та відшкодування завданих збитків

Тип даних:

Ознака

Значення, яке очікується:

Так

Cтатус:

Активна

Дата створення:

12.05.2026 15:07

2. Вчинення економічних правопорушень

Має надати підтвердження по критерію: Учасник

Чого стосується критерій: Тендер

Посилання на законодавство

Група вимог

Підтверджується, що

Вимога

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

Тип даних:

Ознака

Значення, яке очікується:

Так

Cтатус:

Активна

Дата створення:

12.05.2026 15:07

Відповідь на вимогу

Значення:

Так

3. Порушення справи про банкрутство

Має надати підтвердження по критерію: Учасник

Чого стосується критерій: Тендер

Посилання на законодавство

Постанова Про затвердження особливостей здійснення публічних закупівель товарів, робіт і послуг для замовників, передбачених Законом України 'Про публічні закупівлі', на період дії правового режиму воєнного стану в Україні та протягом 90 днів з дня його припинення або скасування від 2026-03-26 Стаття 47.8 Номер 1178-2022-п

Група вимог

Підтверджується, що

Вимога

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

Тип даних:

Ознака

Значення, яке очікується:

Так

Cтатус:

Активна

Дата створення:

12.05.2026 15:07

Відповідь на вимогу

Значення:

Так

4. Наявність антикорупційної програми

Має надати підтвердження по критерію: Учасник

Чого стосується критерій: Тендер

Посилання на законодавство

Постанова Про затвердження особливостей здійснення публічних закупівель товарів, робіт і послуг для замовників, передбачених Законом України 'Про публічні закупівлі', на період дії правового режиму воєнного стану в Україні та протягом 90 днів з дня його припинення або скасування від 2026-03-26 Стаття 47.10 Номер 1178-2022-п

Група вимог

Резидентом підтверджується, що

Вимога

Учасник процедури закупівлі має антикорупційну програму чи уповноваженого з реалізації антикорупційної програми

Тип даних:

Ознака

Значення, яке очікується:

Так

Cтатус:

Активна

Дата створення:

12.05.2026 15:07

Відповідь на вимогу

Значення:

Так

Група вимог

Нерезидентом підтверджується, що

Вимога

Учасник процедури закупівлі є нерезидентом

Тип даних:

Ознака

Значення, яке очікується:

Так

Cтатус:

Активна

Дата створення:

12.05.2026 15:07

5. Вчинення правопорушень, пов?язаних із застосуванням санкцій

Має надати підтвердження по критерію: Учасник

Чого стосується критерій: Тендер

Посилання на законодавство

Група вимог

Підтверджується, що

Вимога

Учасник процедури закупівлі або кінцевий бенефіціарний власник, член або учасник (акціонер) юридичної особи - учасника процедури закупівлі не є особою, до якої застосовано санкцію у вигляді заборони на здійснення у неї публічних закупівель товарів, робіт і послуг згідно із Законом України 'Про санкції', крім випадку, коли активи такої особи в установленому законодавством порядку передані в управління АРМА

Тип даних:

Ознака

Значення, яке очікується:

Так

Cтатус:

Активна

Дата створення:

12.05.2026 15:07

Відповідь на вимогу

Значення:

Так

Вимога

Учасник процедури закупівлі не є громадянином Російської Федерації/Республіки Білорусь/Ісламської Республіки Іран (крім того, що проживає на території України на законних підставах); юридичною особою, утвореною та зареєстрованою відповідно до законодавства Російської Федерації/Республіки Білорусь/Ісламської Республіки Іран; юридичною особою, утвореною та зареєстрованою відповідно до законодавства України, кінцевим бенефіціарним власником, членом або учасником (акціонером), що має частку в статутному капіталі 10 і більше відсотків (далі - активи), якої є Російська Федерація/Республіка Білорусь/Ісламська Республіка Іран, громадянин Російської Федерації/Республіки Білорусь/Ісламської Республіки Іран (крім того, що проживає на території України на законних підставах), або юридичною особою, утвореною та зареєстрованою відповідно до законодавства Російської Федерації/Республіки Білорусь/Ісламської Республіки Іран, крім випадків, коли активи в установленому законодавством порядку передані в управління АРМА

Тип даних:

Ознака

Значення, яке очікується:

Так

Cтатус:

Активна

Дата створення:

12.05.2026 15:07

Відповідь на вимогу

Значення:

Так

Вимога

Учасник процедури закупівлі не пропонує в тендерній пропозиції товари походженням з Російської Федерації/Республіки Білорусь/Ісламської Республіки Іран (за винятком товарів походженням з Російської Федерації/Республіки Білорусь, необхідних для ремонту та обслуговування товарів, придбаних до набрання чинності постановою Кабінету Міністрів України від 12 жовтня 2022 р. № 1178 'Про затвердження особливостей здійснення публічних закупівель товарів, робіт і послуг для замовників, передбачених Законом України 'Про публічні закупівлі', на період дії правового режиму воєнного стану в Україні та протягом 90 днів з дня його припинення або скасування' (Офіційний вісник України, 2022 р., № 84, ст. 5176)

Тип даних:

Ознака

Значення, яке очікується:

Так

Cтатус:

Активна

Дата створення:

12.05.2026 15:07

Відповідь на вимогу

Значення:

Так

6. Наявність інших підстав для відмови в участі у процедурі закупівлі

Має надати підтвердження по критерію: Учасник

Чого стосується критерій: Тендер

Посилання на законодавство

Група вимог

Резидентом підтверджується, що

Вимога

У Єдиному державному реєстрі юридичних осіб, фізичних осіб - підприємців та громадських формувань присутня інформація, передбачена пунктом 9 частини другої статті 9 Закону України 'Про державну реєстрацію юридичних осіб, фізичних осіб - підприємців та громадських формувань'

Тип даних:

Ознака

Значення, яке очікується:

Так

Cтатус:

Активна

Дата створення:

12.05.2026 15:07

Відповідь на вимогу

Значення:

Так

Група вимог

Нерезидентом підтверджується, що

Вимога

Учасник процедури закупівлі є нерезидентом яким було надано повну інформацію про кінцевих бенефіціарних власників, у спосіб, визначений замовником у тендерній документації

Тип даних:

Ознака

Значення, яке очікується:

Так

Cтатус:

Активна

Дата створення:

12.05.2026 15:07

7. Вчинення корупційних правопорушень

Має надати підтвердження по критерію: Переможець

Чого стосується критерій: Тендер

Посилання на законодавство

Група вимог

Юридичною особою підтверджується, що

Вимога

Відомості про учасника процедури закупівлі не внесено до Єдиного державного реєстру осіб, які вчинили корупційні або пов'язані з корупцією правопорушення

Тип даних:

Ознака

Значення, яке очікується:

Так

Cтатус:

Активна

Дата створення:

12.05.2026 15:07

Відповідь на вимогу

Значення:

Так

Вимога

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

Тип даних:

Ознака

Значення, яке очікується:

Так

Cтатус:

Активна

Дата створення:

12.05.2026 15:07

Відповідь на вимогу

Значення:

Так

Група вимог

Фізичною особою підтверджується, що

Вимога

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

Тип даних:

Ознака

Значення, яке очікується:

Так

Cтатус:

Активна

Дата створення:

12.05.2026 15:07

8. Вчинення кримінальних правопорушень

Має надати підтвердження по критерію: Переможець

Чого стосується критерій: Тендер

Посилання на законодавство

Група вимог

Фізичною особою підтверджується, що

Вимога

Учасник процедури закупівлі не був засуджений за кримінальне правопорушення, вчинене з корисливих мотивів (зокрема, пов’язане з хабарництвом та відмиванням коштів), судимість з якої знято або погашено у встановленому законом порядку

Тип даних:

Ознака

Значення, яке очікується:

Так

Cтатус:

Активна

Дата створення:

12.05.2026 15:07

Група вимог

Юридичною особою підтверджується, що

Вимога

Керівник учасника процедури закупівлі не був засуджений за кримінальне правопорушення, вчинене з корисливих мотивів (зокрема, пов’язане з хабарництвом, шахрайством та відмиванням коштів), судимість з якого не знято або не погашено в установленому законом порядку

Тип даних:

Ознака

Значення, яке очікується:

Так

Cтатус:

Активна

Дата створення:

12.05.2026 15:07

Відповідь на вимогу

Значення:

Так

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

Має надати підтвердження по критерію: Переможець

Чого стосується критерій: Тендер

Посилання на законодавство

Постанова Про затвердження особливостей здійснення публічних закупівель товарів, робіт і послуг для замовників, передбачених Законом України 'Про публічні закупівлі', на період дії правового режиму воєнного стану в Україні та протягом 90 днів з дня його припинення або скасування від 2026-03-26 Стаття 47.12 Номер 1178-2022-п

Група вимог

Фізичною особою підтверджується, що

Вимога

Учасника процедури закупівлі не було притягнуто згідно із законом до відповідальності за вчинення правопорушення, пов'язаного з використанням дитячої праці чи будь-якими формами торгівлі людьми

Тип даних:

Ознака

Значення, яке очікується:

Так

Cтатус:

Активна

Дата створення:

12.05.2026 15:07

Група вимог

Юридичною особою підтверджується, що

Вимога

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

Тип даних:

Ознака

Значення, яке очікується:

Так

Cтатус:

Активна

Дата створення:

12.05.2026 15:07

Відповідь на вимогу

Значення:

Так

10. Наявність впливу на прийняття рішення замовника

Має надати підтвердження по критерію: Замовник

Чого стосується критерій: Тендер

Посилання на законодавство

Постанова Про затвердження особливостей здійснення публічних закупівель товарів, робіт і послуг для замовників, передбачених Законом України 'Про публічні закупівлі', на період дії правового режиму воєнного стану в Україні та протягом 90 днів з дня його припинення або скасування від 2026-03-26 Стаття 47.1 Номер 1178-2022-п

Група вимог

Підтверджується, що

Вимога

Учасник процедури закупівлі пропонує, дає або погоджується дати прямо чи опосередковано будь-якій службовій (посадовій) особі замовника, іншого державного органу винагороду в будь-якій формі (пропозиція щодо найму на роботу, цінна річ, послуга тощо) з метою вплинути на прийняття рішення щодо визначення переможця процедури закупівлі або застосування замовником певної процедури закупівлі

Тип даних:

Ознака

Cтатус:

Активна

Дата створення:

12.05.2026 15:07

11. Наявність зв'язку учасника з іншими учасниками процедури або замовником

Має надати підтвердження по критерію: Замовник

Чого стосується критерій: Тендер

Посилання на законодавство

Постанова Про затвердження особливостей здійснення публічних закупівель товарів, робіт і послуг для замовників, передбачених Законом України 'Про публічні закупівлі', на період дії правового режиму воєнного стану в Україні та протягом 90 днів з дня його припинення або скасування від 2026-03-26 Стаття 47.7 Номер 1178-2022-п

Група вимог

Підтверджується, що

Вимога

Учасник процедури закупівлі є пов'язаною особою з іншими учасниками та/або з уповноваженою особою (особами), та/або з керівником замовника

Тип даних:

Ознака

Cтатус:

Активна

Дата створення:

12.05.2026 15:07

1. Наявність обладнання, матеріально-технічної бази та технологій

Має надати підтвердження по критерію: Учасник

Чого стосується критерій: Тендер

Посилання на законодавство

Група вимог

Підтверджується, що

Вимога

Наявність обладнання, матеріально-технічної бази та технологій

Тип даних:

Ознака

Значення, яке очікується:

Так

Cтатус:

Активна

Дата створення:

12.05.2026 15:07

Відповідь на вимогу

Значення:

Так

2. Наявність досвіду виконання аналогічного договору

Має надати підтвердження по критерію: Учасник

Чого стосується критерій: Тендер

Посилання на законодавство

Закон України 'Про публічні закупівлі' від 2025-10-31 Стаття 16.2.3 Номер 922-VIII

Група вимог

Підтверджується, що

Вимога

Наявність досвіду виконання аналогічного договору

Тип даних:

Ознака

Значення, яке очікується:

Так

Cтатус:

Активна

Дата створення:

12.05.2026 15:07

Відповідь на вимогу

Значення:

Так

1. Мова (мови) тендерної пропозиції

Має надати підтвердження по критерію: Учасник

Чого стосується критерій: Тендер

Посилання на законодавство

Закон України 'Про публічні закупівлі' від 2025-10-31 Стаття 22.2.13 Номер 922-VIII

Група вимог

Підтверджується, що

Вимога

Мова тендерної пропозиції

Тип даних:

Текст

Cтатус:

Активна

Дата створення:

12.05.2026 15:07

Значення, яке очікується:

Українська

2. Строк дії тендерної пропозиції

Має надати підтвердження по критерію: Учасник

Чого стосується критерій: Тендер

Посилання на законодавство

Закон України 'Про публічні закупівлі' від 2025-10-31 Стаття 22.2.11 Номер 922-VIII

Група вимог

Підтверджується, що

Вимога

Строк дії тендерної пропозиції із дати кінцевого строку подання тендерних пропозицій

Тип даних:

Ціле число

Cтатус:

Активна

Дата створення:

12.05.2026 15:07

Значення, яке очікується:

120

Відповідь на вимогу

Значення:

120

Назва документа

audit_4a2ef2a9c5b74c46aa57617372f6e4e6_0ec0fa36874b0763088dd471c2a92333.yaml

Тип документа

Дата публікації

26.05.2026 11:42

Дії

Назва документа

sign.p7s

Тип документа

Оголошення про проведення закупівлі

Дата публікації

19.05.2026 17:33

Дії

Попередні версії документу

Назва документа

sign.p7s

Тип документа

Повідомлення про рішення

Дата публікації

18.05.2026 16:18

Назва документа

sign.p7s

Тип документа

Повідомлення про рішення

Дата публікації

14.05.2026 13:48

Назва документа

sign.p7s

Тип документа

Повідомлення про рішення

Дата публікації

12.05.2026 15:12

Назва документа

зі змінами від 19.05.2026 р.ТД Серверне_ мережеве обладнання та матеріали до нього (2) (1).docx

Тип документа

Тендерна документація

Дата публікації

19.05.2026 17:31

Дії

Назва документа

Таблиця Змін до ТЗ СЗД 19-05-2026.docx

Тип документа

Дата публікації

19.05.2026 17:31

Дії

Назва документа

зі змінами від 18.05.2026 р.ТД Серверне_ мережеве обладнання та матеріали до нього (2).docx

Тип документа

Тендерна документація

Дата публікації

18.05.2026 16:13

Дії

Назва документа

Порівняльна таблиця змін 18.05.2026 року.docx

Тип документа

Дата публікації

18.05.2026 16:13

Дії

Назва документа

зі змінами від 14.05.2026 р.ТД Серверне_ мережеве обладнання та матеріали до нього.docx

Тип документа

Тендерна документація

Дата публікації

14.05.2026 13:45

Дії

Попередні версії документу

Назва документа

зі змінами від 14.05.2026 р.ТД Серверне_ мережеве обладнання та матеріали до нього.docx

Тип документа

Тендерна документація

Дата публікації

14.05.2026 13:42

Назва документа

Зміни в ТД 14.05.2026.docx

Тип документа

Дата публікації

14.05.2026 13:42

Дії

Назва документа

ТД Серверне_ мережеве обладнання та матеріали до нього 12.05.2026.docx

Тип документа

Тендерна документація

Дата публікації

12.05.2026 15:07

Дії

Назва документа

Проєкт договору Додаток 3.docx

Тип документа

Проект договору

Дата публікації

12.05.2026 15:07

Дії

Контактна особа

Відповідальний за закупівлю:

Пятаєва Олександра Олексіївна

Відповідальний за закупівлю (англійською мовою):

Електронна пошта:

[email protected]

Телефон:

+380444940588

Замовник

ЄДРПОУ:

44673629

Назва:

Державна організація "Український національний офіс інтелектуальної власності та інновацій"

Повна назва:

Державна організація "Український національний офіс інтелектуальної власності та інновацій"

Поштовий індекс:

01601

Країна:

Україна

Область або регіон:

м. Київ

Населений пункт:

Київ

Адреса:

вул. Дмитра Годзенка,1

Кваліфікація

ТОВАРИСТВО З ОБМЕЖЕНОЮ ВІДПОВІДАЛЬНІСТЮ "БІЗНЕС КОНТІНЮІТІ СОЛЮШНЗ"

Період вимог/скарг з 27.05.2026 15:27 по 02.06.2026 00:00

Період розгляду тендерної пропозиції з 26.05.2026 11:42 по 03.06.2026 00:00

Показати документи пропозиції

Відповіді на критерії

Кваліфікований електронний підпис накладено.

Документи кваліфікації

Назва документа

napc

Тип документа

Довідка НАЗК

Дата публікації

27.05.2026 15:27

Дії

Назва документа

sign.p7s

Тип документа

Повідомлення про рішення

Дата публікації

27.05.2026 15:27

Дії

Назва документа

Протокол _74 від 27.05.2026.pdf

Тип документа

Дата публікації

27.05.2026 15:26

Дії

Назва документа

edr_40155256_registered.yaml

Тип документа

documentType.award.registerUSR

Дата публікації

26.05.2026 11:42

Дії

Договір

UA-2026-05-12-010741-a-a1

Очікує підписання

Ціна договору:

43 425 000 грн.

Ознака ПДВ в договорі:

З ПДВ

Ціна договору без ПДВ:

43 425 000 грн.

Номенклатура

644 штуки

Серверне, мережеве обладнання та матеріали до нього

Номенклатура:

Серверне, мережеве обладнання та матеріали до нього

Кількість:

644

Одиниця виміру:

штуки

Ціна за одиницю:

Валюта:

UAH

Ознака ПДВ ціни за одиницю:

З ПДВ

Кінцева дата поставки:

середа, 9 грудня 2026 р.

Умови поставки та здійснення розрахунків

Умови оплати

№	Подiя	Тип оплати	Період, (днів)	Тип днів	Розмір оплати, %
1	Поставка товару	Аванс	20	робочі	5
2	Поставка товару	Пiсляоплата	20	робочі	95

Умови поставки

№	Подiя	Тип поставки	Період, (днів)	Тип днів	Розмір поставки, %
3	Підписання договору	Одноразова поставка	180	календарні	100

Покупець

Статус:

В очікуванні

Коротка назва:

Державна організація "Український національний офіс інтелектуальної власності та інновацій"

Повна назва:

Державна організація "Український національний офіс інтелектуальної власності та інновацій"

Місцезнаходження:

Україна

Реєстр:

ЄДРПОУ

Код ЄДРПОУ:

44673629

Постачальник

Статус:

В очікуванні

Коротка назва:

ТОВАРИСТВО З ОБМЕЖЕНОЮ ВІДПОВІДАЛЬНІСТЮ "БІЗНЕС КОНТІНЮІТІ СОЛЮШНЗ"

Повна назва:

ТОВАРИСТВО З ОБМЕЖЕНОЮ ВІДПОВІДАЛЬНІСТЮ "БІЗНЕС КОНТІНЮІТІ СОЛЮШНЗ"

Місцезнаходження:

Україна

Реєстр:

ЄДРПОУ

Код ЄДРПОУ:

40155256

Інформація про підписанта

Серверне, мережеве обладнання та матеріали до нього

Звернення за тендером: Серверне, мережеве обладнання та матеріали до нього

Тема: Щодо документів офіційно го ввезення на територію України

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

Дата оприлюднення звернення: 13.05.2026 22:51

Доброго дня. Для підтвердження якісних характеристик товару («Все обладнання комплексу повинно бути новим та таким, що не було у використанні та не було відновленим. Обладнання комплексу повинно ввозитися на територію України через офіційні канали поставки, та з відповідним гарантійним сервісом виробника» та «Товар, що поставляється, має бути новим, невикористаним, упакованим») у складі тендерної пропозиції Учасник має надати копію авторизаційного листа від виробника запропонованого товару та/або послуг (сервери віртуалізації, комутатор, система збереження даних), або його офіційного представництва в Україні, що підтверджує партнерські відносини між Учасником та цим Виробником та право Учасника на надання послуг та/або постачання запропонованого товару та/або послуг. У разі надання авторизаційного листа іноземною мовою, цей лист повинен супроводжуватись перекладом на українську мову. Дякуємо за запитання. Уточнення буде внесено в ТД Замовника.

Дата оприлюднення відповіді: 14.05.2026 13:28

Звернення за тендером: Серверне, мережеве обладнання та матеріали до нього

Тема: Щодо документів переможця

Зміст: У розділі 3 Тендерна документація каже, що переможець подає документи, встановлені в Додатку 1 «для переможця». Водночас окремо в самому файлі існує Додаток 4 під назвою «Перелік документів та/або інформації, які подаються Переможцем процедури закупівлі». Це створює колізію: який саме додаток застосовується до переможця — Додаток 1 чи Додаток 4. Документація повинна бути чіткою та однозначною, а вимоги — сформованими так, щоб учасник міг однозначно зрозуміти обсяг своїх обов’язків; це випливає зі статті 22 Закону та принципів відкритості, рівного ставлення й об’єктивного визначення переможця. Враховуючи викладене, просимо уточнити, який саме додаток є вичерпним переліком документів переможця: Додаток 1 чи Додаток 4.

Дата оприлюднення звернення: 15.05.2026 10:48

Шановний учаснику! Дякуємо за звернення. Відповідно до Особливостей, затверджених постановою КМУ України від 12.10.2022 р. № 1178 ( зі змінами), переможець процедур закупівлі зобов’язаний надати всі необхідні документи та інформацію, які передбачені замовником у тендерній документації. Вимоги до переможця безпосередньо містяться у Додатку 1 та у Додатку 4 тендерної документації. Зазначені вимоги не суперечать одна одній, а є взаємодоповнюючими. Переможець процедури закупівлі у строк, що не перевищує чотири дні з дати оприлюднення в електронній системі закупівель повідомлення про намір укласти договір про закупівлю, повинен надати замовнику шляхом оприлюднення в електронній системі закупівель документи, що підтверджують відсутність підстав, зазначених у пункті 47 Особливостей, у повному обсязі та відповідно до вимог, визначених у Додатку 1 та у Додатку 4 тендерної документації.

Дата оприлюднення відповіді: 17.05.2026 16:45

Звернення за тендером: Серверне, мережеве обладнання та матеріали до нього

Тема: Сервісний центр виробника

Зміст: Для серверів Тендерна документація вимагає офіційний сервісний центр виробника на території України, для СЗД — авторизований сервісний центр в Україні, а для комутатора — гарантію 36 місяців 9x5 NBD із виїздом інженера. Такі вимоги можуть бути обґрунтовані лише за наявності реальної операційної необхідності, але у нинішньому вигляді вони обмежують коло учасників тими постачальниками, які вже мають певну сервісну інфраструктуру саме в Україні, навіть якщо інші учасники здатні забезпечити еквівалентний SLA через партнерські мережі або контрактну модель сервісу. Окремо звертаємо увагу на неузгодженість формулювань: для одного обладнання вимагається «офіційний сервісний центр виробника», для іншого — «авторизований сервісний центр». Враховуючи викладене, просимо обґрунтувати чому вимога сформульована саме як наявність сервісного центру в Україні, а не як обов’язок переможця забезпечити конкретні строки реакції, заміни та відновлення працездатності незалежно від власної сервісної моделі.

Дата оприлюднення звернення: 15.05.2026 10:50

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

Дата оприлюднення відповіді: 17.05.2026 16:50

Звернення за тендером: Серверне, мережеве обладнання та матеріали до нього

Тема: Критерії прийнятності сервісу

Зміст: Для сервера вимагається офіційний сервісний центр виробника на території України, для СЗД — авторизований сервісний центр, для комутатора — 9x5 NBD з виїздом інженера, але без такого ж чіткого формулювання про сервісний центр. Документація не пояснює, чому для схожого класу критичної ІТ?інфраструктури застосовуються різні критерії прийнятності сервісу. Це створює простір для неоднакового тлумачення. Просимо уніфікувати сервісні вимоги або окремо пояснити, чому для різних позицій використано різні критерії прийнятності сервісу.

Дата оприлюднення звернення: 15.05.2026 10:52

Дата оприлюднення відповіді: 17.05.2026 16:51

Звернення за тендером: Серверне, мережеве обладнання та матеріали до нього

Тема: Офіційне ввезення товарів

Зміст: Вимога Тендерної документації Замовника щодо надання підтвердження того, що обладнання "офіційно ввезене на територію України" на стадії подання тендерної пропозиції, є дискримінаційною. Порушується стаття 5 Закону України "Про публічні закупівлі", оскільки, дана вимога обмежує коло учасників лише тими суб’єктами господарювання, які вже мають запропонований товар на складі в Україні. Це унеможливлює участь офіційних партнерів виробників, які здійснюють поставку обладнання під замовлення. Також Замовником в Тендерній документації зазначено, що підтвердженням "офіційно ввезеним на територію України" є авторизаційний лист. Проте авторизаційний лист підтверджує лише право на поставку та партнерство, а не факт перетину кордону (що підтверджується митною декларацією), що додатково підтверджує вищевикладене. Просимо привести Тендерну документацію у відповідність та усунути дискримінаційні норми.

Дата оприлюднення звернення: 15.05.2026 10:53

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

Дата оприлюднення відповіді: 17.05.2026 16:51

Звернення за тендером: Серверне, мережеве обладнання та матеріали до нього

Тема: Вимоги до комутаторів

Зміст: Шановний Замовнику! Під час технічного аналізу опублікованих вимог до комутаторів встановлено, що сукупність технічних характеристик, передбачених тендерною документацією, не може бути одночасно забезпечена жодним із провідних світових виробників мережевого обладнання західного походження — зокрема Cisco Systems, Juniper Networks (HPE Juniper Networking), NVIDIA (Mellanox), Dell Technologies, Arista Networks, Extreme Networks та HPE Aruba. Зокрема, наступна комбінація вимог в одному пристрої 1U не реалізована в жодній актуальній моделі зазначених виробників: 1. Портова конфігурація — не менше 24 портів 25G SFP28 одночасно з не менше 8 портами 40/100G QSFP28 в форм-факторі 1U; 2. Стекування не менше 4 пристроїв через Ethernet-порти з відмовостійкістю 1:N, географічним рознесенням стеку та єдиною консоллю керування — водночас із повним функціоналом дата-центру (VXLAN L2/L3, EVPN, MPLS, MPLS VPN, VPLS, MCE); 3. Вбудований у комутатор контролер бездротових мереж Wi-Fi з підтримкою не менше 256 точок доступу (за додаткове ліцензування); 4. Підтримка протоколу G.8032 ERPS одночасно з повним L3-стеком (BGP, OSPF, IS-IS, MPLS); 5. Підтримка CWMP-TR069 — протокол, який у західній галузі застосовується переважно у CPE/операторському обладнанні, а не в комутаторах рівня дата-центру; 6. MTBF не менше 61,4 років — значення, яке у такому формулюванні публікують саме китайські виробники (Huawei, H3C); західні вендори зазначають MTBF у годинах, і типові значення (200 000–270 000 годин ? 22–30 років) НЕ задовольняють цю вимогу; 7. Вбудований функціонал управління групами пристроїв із побудовою графічної топології та централізованим оновленням ПЗ безпосередньо засобами комутатора (а не зовнішньої системи керування). Зазначений набір вимог в єдиному виробі характерний виключно для модельного ряду комутаторів китайського виробника H3C (серія S6850), та, можливо, Huawei, що фактично обмежує конкуренцію та звужує коло потенційних учасників закупівлі до одного (або двох) постачальника обладнання походженням з КНР. З огляду на: • вимоги статті 5 Закону України «Про публічні закупівлі» щодо принципів добросовісної конкуренції, недискримінації учасників та відкритості закупівель; • частину 4 статті 22 Закону України «Про публічні закупівлі», що забороняє включення до тендерної документації вимог, які обмежують конкуренцію та призводять до дискримінації учасників; • ризики у сфері кібербезпеки критичної інформаційної інфраструктури просимо Замовника внести наступні зміни до тендерної документації: Порти: у вимозі «Не менше ніж 8 портів 40/100 Гбіт/с QSFP28.» пропонуємо змінити на «Не менше ніж 6 портів 40/100 Гбіт/с QSFP28». Оскільки у більшості дата центрових архітектур (в тому числі і Spine Leaf) використання 6 uplink портів є типовим і повністю покриває потреби у пропускній здатності, пропонуємо зменшити кількість портів до 6. Така зміна відкриває можливість пропозиції моделей Cisco, Juniper, Dell та аналогічних від інших виробників. Продуктивність: виключити вимоги «Апаратна пропускна здатність процесора: Не менше 4.8 Тбіт/с.» та «Пропуск пересилання пакетів: Не менше 1920 Мп/с.» Оскільки більшість сучасних вендорів в специфікаціях обладнання спираються на загальну пропускну здатність комутатора пропонуємо залишити як параметр оцінки «Пропускна здатність», інші виключити. Тим більше пропускна здатність процесора не має ніякого відношення до пропускної здатності конкретного комутатора, де є обмеження по кількості портів. Пропонуємо залишити як параметр оцінки лише «Пропускна здатність комутатора не менше 2.8 Тбіт/с». Просимо виключити вимоги про стекування «Стекування не менше 4 пристроїв використовуючи порти Ethernet. Відмовостійкість стека 1:N - можливість передання ролі майстра на будь-який доступний пристрій. Можливість організації стека географічно рознесених пристроїв. Можливість організації link aggregation з балансуванням навантаження на різних пристроях у стеку. Можливість управління з єдиної консолі всього стека комутаторів.» оскільки це нетипова для DC-комутаторів вимога (це більше «кампусна» парадигма стека). Більшість сучасних дата-центрових платформ західних виробників (Cisco Nexus, Juniper QFX, Arista, Dell PowerSwitch) свідомо не підтримують класичне стекування як архітектурне рішення, натомість пропонуючи технології Multi-Chassis LAG (MC-LAG, VLT, ESI-LAG) та overlay-фабрики (VXLAN EVPN), які забезпечують вищу відмовостійкість та масштабованість. Технологія географічно-рознесеного стеку через виділені Ethernet-порти у поєднанні з повним DC-функціоналом є унікальною для платформ Huawei (iStack/CSS) та H3C (IRF). Замість зазначеної вимоги пропонуємо: «Підтримка технологій Multi-Chassis Link Aggregation (MC-LAG, VLT, ESI-LAG або еквівалент) для забезпечення active-active підключення хостів до двох комутаторів». Живлення: у вимозі «П’ять відсіків для вентиляторів гарячої заміни» пропонуємо змінити пункт на «Можливість гарячої заміни вентиляторів», оскільки кількість вентиляторних відсіків відрізняється у залежності від виробника та моделі і не впливає на функціональні характеристики.. У вимозі «Робочий діапазон -5°C to +45°C.» змінити на «0°C to +40°C» оскільки використання обладнання у середовищі з температурою нижче 0°C або вище +40°C не є типовим для дата центрів і не відповідає стандартним практикам експлуатації дата-центрів (ASHRAE Class A1-A2). Серверне обладнання та системи зберігання даних, які підключаються до комутаторів, також не розраховані на роботу при від'ємних температурах. У вимозі «Середній час напрацювання на відмову (MTBF), не менше 61.4 років.» просимо MTBF ?61,4 років слід замінити на строк галузевих стандартів (20–30 років), оскільки обладнання не використовується протягом такого тривалого часу. Вимога у 61,4 років є теоретичною і завищеною та не має практичного сенсу, оскільки обладнання у дата центрах оновлюється кожні 5–10 років через технологічний цикл. Пропонуємо замінити на не менше 20 років. Функціонал L2: У вимозі «BPDU Blocking and Root Guard G.8032 ERPS (Ethernet Ring Protection Switching).» пропонуємо замінити на «BPDU Blocking and Root Guard» оскільки протокол G.8032 ERPS є стандартом для операторських мереж (Metro Ethernet), а не мереж датацентрів , де використовуються MC-LAG, VXLAN EVPN та ECMP. У вимозі «Розмір пакетів Jumbo щонайменше 13312 bytes.» пропонуємо змінити вимогу «Jumbo Frames до не менше 9000 bytes», що відповідає галузевим стандартам, (RFC, де-факто прийнятому Cisco, Juniper, Arista, Dell, NVIDIA) та повністю задовольняє потреби дата-центрових застосувань, зокрема iSCSI, NVMe-oF та RoCE. Значення 13 312 bytes публікує саме Huawei. Функціонал L3: У вимогах «RIPv1/v2 і RIPng. OSPFv1/v2 and OSPFv3.» пропонуємо виключити вимогу підтримки RIPv1 та OSPFv1 як застарілу та таку, що не має практичного застосування у сучасних дата центрових мережах. Замість цього слід орієнтуватися на підтримку сучасних протоколів (OSPFv2/v3, BGP, IS IS, VXLAN EVPN), які відповідають актуальним стандартам і забезпечують масштабованість та безпеку. У вимозі «Підтримка зон OSPF Areas: не менше 128.» просимо змінити на «Підтримка зон OSPF Areas: не менше 64.», що відповідає галузевим стандартам, практичним сценаріям використання та забезпечує оптимальне співвідношення функціональності й вартості. У вимозі «DHCP server.» пропонуємо виключити вимогу підтримки DHCP Server на комутаторі, оскільки це не відповідає сучасним архітектурним практикам дата центрів. Замість цього використовується централізований DHCP сервіс із підтримкою DHCP Relay на комутаторі, що забезпечує необхідну функціональність. Пропонуємо виключити вимогу «MVRP.» як застарілу та таку, що не має практичного застосування у сучасних дата центрових мережах. Пропонуємо виключити вимогу підтримки «MPLS VPN, VPLS.» як таку, що орієнтована на операторські мережі, а не на дата центрові рішення. Замість цього слід орієнтуватися на підтримку VXLAN EVPN, яка забезпечуює аналогічну функціональність у сучасних дата центрах. Пропонуємо виключити вимогу підтримки «Multi-VPN Instance Customer Edge (MCE).» Термін «MCE» є специфічною термінологією Huawei та H3C. Безпека: Пропонуємо виключити вимогу підтримки «Port security.» як таку, що орієнтована на кампусні мережі, а не на дата центрові рішення. Замість цього слід орієнтуватися на підтримку сучасних механізмів безпеки (802.1X, ACL, CoPP, VXLAN EVPN), які забезпечують масштабованість, централізоване управління та високий рівень захисту. Функціонал керування: Пропонується виключити вимогу підтримки «CWMP TR069», оскільки цей протокол орієнтований на операторські CPE пристрої, а не на дата центрові комутатори. У дата-центрах для централізованого керування використовуються інші технології, які забезпечують значно ширші можливості автоматизації. Пропонується виключити вимогу підтримки «802.1ag і 802.3ah.» як таку, що не має практичного застосування у дата центрових середовищах, оскільки ці протоколи призначені для операторських мереж (Carrier Ethernet) та використовуються для діагностики та управління сервісами у магістральних мережах. Пропонуємо виключити вимоги «Можливість розгортання вбудованого контролера для мереж Wi-Fi за додаткове ліцензування. Підтримка керування щонайменше 256 точками доступу.», оскільки вони не відповідають профілю дата центрового комутатора. У корпоративних мережах Wi Fi контролери реалізуються окремими спеціалізованими пристроями або хмарними сервісами (Cisco Catalyst 9800, Juniper Mist, HPE Aruba Central тощо). Вбудований WLC у Ethernet-комутатор є характерною рисою саме модельного ряду Huawei та H3C. Вимогу «Наявність вбудованого в комутатор функціоналу управління груп пристроїв, з побудовою графічної топології, централізованим оновленням ПЗ і роботою з конфігураціями пристроїв.» слід адаптувати до використання зовнішніх систем управління, що відповідає сучасним практикам корпоративного управління мережею. Вимогу «Підтримка системою одночасно безлічі функцій авторизацій (авторизація за MAC адресами, 802.1Х, Web портал).» слід адаптувати до підтримки стандартних механізмів авторизації (802.1X, MAC), а Web портал винести на зовнішні рішення. З огляду на викладене, просимо Замовника: 1. Внести зазначені зміни до технічного завдання тендерної документації з метою забезпечення дотримання принципів недискримінації та добросовісної конкуренції; 2. Опублікувати оновлену редакцію тендерної документації з обґрунтованим продовженням строку подання тендерних пропозицій; 3. У разі незгоди з пропонованими змінами — надати технічне обґрунтування необхідності кожної з оскаржуваних вимог саме у заявленому формулюванні, із зазначенням переліку моделей провідних світових виробників (Cisco, Juniper/HPE, NVIDIA, Dell, Arista, Extreme, HPE Aruba), які, на думку Замовника, відповідають усій сукупності опублікованих технічних вимог. Звертаємо увагу, що збереження оскаржуваних вимог у чинній редакції створює підстави для звернення зацікавлених учасників до Антимонопольного комітету України з скаргою на дискримінаційні умови тендерної документації відповідно до статті 18 Закону України «Про публічні закупівлі».

Дата оприлюднення звернення: 15.05.2026 14:20

Добрий день, шановний учаснику, дякуємо за запитання. Зміни внесено в ТД.

Дата оприлюднення відповіді: 18.05.2026 16:15

Звернення за тендером: Серверне, мережеве обладнання та матеріали до нього

Тема: Щодо технічних вимог до комутаторів

Зміст: Шановний Замовнику! За результатами аналізу технічних вимог до комутаторів ми встановили, що сукупність технічних характеристик, заданих у технічній документації, забезпечується лише одним варіантом комутатору, а саме – моделлю H3C S6530X-24Y8C. А саме, сукупність наступних характеристик: 1. не менше 24 портів 25G SFP28 одночасно з не менше 8 портами 40/100G QSFP28 в форм-факторі 1U; 2. стекування через Ethernet-порти з відмовостійкістю, географічним рознесенням стеку та єдиною консоллю керування, водночас із повним функціоналом дата-центру та обладнання провайдерсько-операторського призначення (VXLAN L2/L3, EVPN, MPLS, MPLS VPN, VPLS, MCE); 3. вбудований у комутатор контролер бездротових мереж Wi-Fi; 4. підтримка низки протоколів операторсько-провайдерського признаяення: G.8032 ERPS, CWMP-TR069; 5. параметр MTBF, визначений у роках, а не у годинах; 6. вбудований функціонал управління групами пристроїв із побудовою графічної топології та централізованим оновленням ПЗ безпосередньо засобами комутатора (а не зовнішньої системи керування). та деяких інших характеристик. На підставах цього аналізу ми зробили висновок, що дане ТЗ зроблено під одну конкретну модель комутатору, що фактично обмежує конкуренцію та звужує коло потенційних учасників закупівлі до одного постачальника обладнання походженням з КНР. З огляду на: • вимоги статті 5 Закону України «Про публічні закупівлі» щодо принципів добросовісної конкуренції, недискримінації учасників та відкритості закупівель; • частину 4 статті 22 Закону України «Про публічні закупівлі», що забороняє включення до тендерної документації вимог, які обмежують конкуренцію та призводять до дискримінації учасників; • ризики у сфері кібербезпеки критичної інформаційної інфраструктури переконливо просимо Замовника внести наступні зміни до тендерної документації: 1. Порти: у вимозі «Не менше ніж 8 портів 40/100 Гбіт/с QSFP28» пропонуємо змінити на «Не менше ніж 6 портів 40/100 Гбіт/с QSFP28», оскільки у більшості дата центрових архітектур використання 6 uplink портів є типовим і повністю покриває потреби у пропускній здатності. Така зміна відкриває можливість пропозиції моделей інших провідних світових виробників. 2. Продуктивність: виключити вимоги «Апаратна пропускна здатність процесора: Не менше 4.8 Тбіт/с.». Оскільки більшість сучасних вендорів в специфікаціях обладнання спираються на загальну пропускну здатність комутатора пропонуємо залишити як параметр оцінки тільки «Пропускна здатність» та «Пропуск пересилання пакетів». 3. Просимо виключити вимоги про стекування «Стекування не менше 4 пристроїв використовуючи порти Ethernet. Відмовостійкість стека 1:N - можливість передання ролі майстра на будь-який доступний пристрій. Можливість організації стека географічно рознесених пристроїв. Можливість організації link aggregation з балансуванням навантаження на різних пристроях у стеку. Можливість управління з єдиної консолі всього стека комутаторів.» оскільки це нетипова для DC-комутаторів вимога. Більшість сучасних дата-центрових платформ західних виробників (Cisco Nexus, Juniper QFX, Arista, Dell PowerSwitch) свідомо не підтримують класичне стекування як архітектурне рішення, натомість пропонуючи технології Multi-Chassis LAG (MC-LAG, VLT, ESI-LAG) та overlay-фабрики (VXLAN EVPN), які забезпечують вищу відмовостійкість та масштабованість. Замість зазначеної вимоги пропонуємо: «Підтримка технологій Multi-Chassis Link Aggregation (MC-LAG, VLT, ESI-LAG або еквівалент) для забезпечення active-active підключення хостів до двох комутаторів». 4. Живлення: у вимозі «Можливість встановлення БЖ різного типу живлення (AC або DC)» пропонуємо видалити підтримку БЖ постійного струму (DC), оскільки DC-живлення характерне тільки для мереж операторів зв’язку, а не для типового ЦОДу корпоративної мережі. 5. У вимозі «Робочий діапазон -5°C to +45°C.» змінити на «0°C to +40°C» оскільки використання обладнання у середовищі з температурою нижче 0°C або вище +40°C не є типовим для дата центрів і не відповідає стандартним практикам експлуатації дата-центрів (ASHRAE Class A1-A2). Серверне обладнання та системи зберігання даних, які підключаються до комутаторів, також не розраховані на роботу при від'ємних температурах. 6. У вимозі «Середній час напрацювання на відмову (MTBF), не менше 61.4 років.» просимо MTBF ?61,4 років слід замінити на строк галузевих стандартів (20–30 років), оскільки обладнання не використовується протягом такого тривалого часу. Вимога у 61,4 років є теоретичною і завищеною та не має практичного сенсу, оскільки обладнання у дата центрах оновлюється кожні 5–10 років через технологічний цикл. Пропонуємо замінити на не менше 20 років. 7. Функціонал L2: У вимозі «BPDU Blocking and Root Guard G.8032 ERPS (Ethernet Ring Protection Switching).» пропонуємо замінити на «BPDU Blocking and Root Guard» оскільки протокол G.8032 ERPS є релевантним для операторських мереж (Metro Ethernet), а не для корпоративної мережевої інфраструктури у ЦОДах. 8. Функціонал L2: вимогу «802.1ad QinQ і selective QinQ.» видалити, оскільки ця функція є релевантною для провайдерсько-операторських мережевих інфраструктур, і не є характерною для мереж типових корпоративних ЦОДів. 9. Функціонал L2: у вимозі «Розмір пакетів Jumbo щонайменше 13312 bytes.» пропонуємо змінити вимогу «Jumbo Frames до не менше 9k», що відповідає галузевим стандартам, та повністю задовольняє потреби дата-центрових застосувань, зокрема iSCSI, NVMe-oF та RoCE. 10. Функціонал L3: У вимогах «RIPv1/v2 і RIPng. OSPFv1/v2 and OSPFv3.» пропонуємо виключити вимогу підтримки RIPv1 та OSPFv1 як застарілу та таку, що не має практичного застосування у сучасних корпоративних мережах. 11. Функціонал L3: видалити вимогу підтримки протоколу «IS-IS», оскільки цей протокол маршрутизації є характерним для провайдерсько-операторських мережевих інфраструктур, і не є характерним для типових корпоративних мереж. 12. Функціонал L3: видалити вимогу «Підтримка суміжності OSPF Adjacencies: не менше 512» , оскільки така кількість є характерною для провайдерсько-операторських мережевих інфраструктур, і не є характерним для типових корпоративних мереж. 13. Пропонуємо виключити вимогу «MVRP» як застарілу та таку, що не має практичного застосування у сучасних типових корпоративних мережах. 14. Пропонуємо виключити вимогу підтримки «MPLS VPN, VPLS» як таку, що орієнтована на операторські мережі, а не на дата центрові рішення. 15. Пропонуємо виключити вимогу підтримки «Multi-VPN Instance Customer Edge (MCE).» Термін «MCE» є специфічною термінологією Huawei та H3C. 16. Функціонал керування: Пропонуємо виключити вимогу підтримки «CWMP TR069», оскільки цей протокол орієнтований на операторські CPE пристрої, а не на дата центрові комутатори. 17. Пропонується виключити вимогу підтримки «802.1ag і 802.3ah.» як таку, що не має практичного застосування у дата центрових середовищах, оскільки ці протоколи призначені для операторських мереж (Carrier Ethernet) та використовуються для діагностики та управління сервісами у магістральних мережах. 18. Пропонуємо виключити вимоги «Можливість розгортання вбудованого контролера для мереж Wi-Fi за додаткове ліцензування. Підтримка керування щонайменше 256 точками доступу.», оскільки вони не відповідають профілю дата центрового комутатора. 19. Пропонуємо адаптувати вимогу «Наявність вбудованого в комутатор функціоналу управління груп пристроїв, з побудовою графічної топології, централізованим оновленням ПЗ і роботою з конфігураціями пристроїв» до використання зовнішніх систем управління, що відповідає сучасним практикам корпоративного управління мережею. 20. Пропонуємо адаптувати вимогу «Підтримка системою одночасно безлічі функцій авторизацій (авторизація за MAC адресами, 802.1Х, Web портал).» до підтримки стандартних механізмів авторизації (802.1X, MAC), а Web-портал винести на зовнішні рішення. З огляду на викладене, просимо Замовника: 1. Внести зазначені зміни до технічного завдання тендерної документації з метою забезпечення дотримання принципів недискримінації та добросовісної конкуренції; 2. Опублікувати оновлену редакцію тендерної документації з обґрунтованим продовженням строку подання тендерних пропозицій; 3. У разі незгоди з пропонованими змінами — надати технічне обґрунтування необхідності кожної з оскаржуваних вимог саме у заявленому формулюванні, із зазначенням переліку моделей провідних світових виробників (Cisco, Juniper/HPE, NVIDIA, Dell, Arista, Extreme, HPE Aruba), які, на думку Замовника, відповідають усій сукупності опублікованих технічних вимог. Звертаємо увагу, що збереження оскаржуваних вимог у чинній редакції створює підстави для звернення зацікавлених учасників до Антимонопольного комітету України з скаргою на дискримінаційні умови тендерної документації відповідно до статті 18 Закону України «Про публічні закупівлі».

Дата оприлюднення звернення: 15.05.2026 19:59

Добрий день, шановний учаснику, дякуємо за запитання. Зміни внесено в ТД.

Дата оприлюднення відповіді: 18.05.2026 16:16

Звернення за тендером: Серверне, мережеве обладнання та матеріали до нього

Тема: Щодо технічних вимог до СЗД

Зміст: Шановний Замовнику! Під час технічного аналізу опублікованих вимог до системи зберігання даних встановлено, що сукупність технічних характеристик, передбачених тендерною документацією, у заявленому формулюванні може бути забезпечена виключно одним виробником — NetApp (на операційній системі ONTAP). Інші провідні виробники систем зберігання даних корпоративного класу — Dell, HPE, Hitachi Vantara, IBM, Huawei — не здатні одночасно забезпечити всі заявлені вимоги. При цьому окремі лінійки виробників Lenovo (серії ThinkSystem DM та DG) та Fujitsu (серії ETERNUS AX та HX), які формально відповідають вимогам, є OEM-системами NetApp на тій же ОС ONTAP, що документально підтверджено офіційними джерелами цих виробників: (1) Lenovo ThinkSystem DM/DG = NetApp ONTAP: • Офіційний пресреліз Lenovo від 13.09.2018 про створення спільних продуктів ThinkSystem DM/DE на технологічній платформі NetApp ONTAP: https://news.lenovo.com/pressroom/press-releases/lenovo-and-netapp-form-global-strategic-partnership-to-accelerate-customers-digital-transformation/ • Офіційне security advisory Lenovo Product Security (PS500603), у якому Lenovo сама визнає, що системи ThinkSystem DM використовують NetApp Clustered Data ONTAP та успадковують вразливості NetApp (CVE-2019-5493 та інші): https://support.lenovo.com/us/en/product_security/ps500603-netapp-information-disclosure-vulnerability • Технічна документація Lenovo Support щодо оновлення прошивки контролерів ThinkSystem DM через Lenovo Data ONTAP CLI: https://support.lenovo.com/us/en/solutions/ht511575 • Product Guide Lenovo ThinkSystem DM3010H, у якому прямо зазначено: «ONTAP software version 9.13.1P1», «RAID-4, RAID-DP, RAID-TEC» — фірмові технології NetApp: https://lenovopress.lenovo.com/lp1793.pdf (2) Fujitsu ETERNUS AX/HX = NetApp ONTAP: • Офіційний пресреліз Fujitsu від 30.06.2020, де Fujitsu прямо заявляє: «Наші нові FUJITSU Storage ETERNUS AX / ETERNUS HX системи… продаватимуться в Європі під брендом NetApp, відомі як родини систем NetApp AFF та NetApp FAS»: https://info.archives.global.fujitsu/global/about/resources/news/press-releases/2020/0630-01.html • Офіційний експлуатаційний документ Fujitsu (Maintenance Manual ETERNUS AX/HX, p3ag-5552-en), де прямо описано команди ONTAP CLI як штатні засоби обслуговування: https://sp.ts.fujitsu.com/dmsp/Publications/public/p3ag-5552-en.pdf Таким чином, коло потенційних учасників закупівлі фактично обмежено постачальниками одного виробника, що унеможливлює реальну конкуренцію в межах процедури. ________________________________________ І. Суперечність технічного завдання Окремо звертаємо увагу на наявну в тендерній документації взаємовиключну суперечність технічних вимог, що сама по собі є підставою для перегляду формулювань: • Розділ «Архітектура» встановлює: «СЗД повинен підтримувати можливість виходу з ладу до 3 дисків одночасно» — що технічно відповідає схемі захисту з трьома блоками парності (triple parity, RAID-TEC, RAID-TP); • Розділ «Накопичувачі» одночасно встановлює: «Загальний корисний дисковий простір має бути не менше 197 TiB… в режимі RAID з 2 дисками парності (parity)» — що відповідає схемі захисту з двома блоками парності (RAID-6, RAID-DP). Жоден сучасний масив не може одночасно забезпечити обидві вимоги в межах одного pool/aggregate, оскільки кількість блоків парності в RAID-групі є фізично взаємовиключною характеристикою. Виконання обох вимог одночасно є об'єктивно неможливим, що робить тендерну документацію в цій частині суперечливою та такою, що не може бути виконана учасниками без додаткових роз'яснень. ________________________________________ ІІ. Перелік вимог, які мають дискримінаційні ознаки Наведена нижче комбінація вимог в одному пристрої є характерною виключно для модельного ряду СЗД NetApp (з ОС ONTAP) та OEM-систем Lenovo ThinkSystem DM/DG і Fujitsu ETERNUS AX/HX (також з ОС ONTAP): 1. «СЗД повинен підтримувати можливість виходу з ладу до 3 дисків одночасно» (Архітектура); 2. «Підключення дискових полиць має бути реалізоване за допомогою 100Gb інтерфейсів протоколами RoCE або аналогічних технологій» (Архітектура); 3. «Можливість логічного поділу СЗД на віртуальні з окремими адресами керування» (Архітектура); 4. «Для створення кластера на рівні СЗД повинні використовуватися порти 100Gb по 2 на контролер» (Встановлені порти СЗД); 5. «Наявність мінімум 8 портів 25Gb iSCSI в комплекті з DAC-кабелями 25GB SFP28-SFP28 Cu, 2м» (Встановлені порти СЗД); 6. «СЗД не повинна використовувати окремі фізичні носії для зберігання операційної системи» (Архітектура); 7. «Можливість захисту даних за допомогою шифрування (на носіях будь-якого типу)» (Технології зберігання даних СЗД); 8. «Система повинна мати можливість створення снапшотів, що не впливає на продуктивність СЗД. При цьому має підтримуватись до 2?10^6 снапшотів на одну систему» (Додаткові вимоги СЗД); 9. «Можливість робити гранульовані снапшоти окремого ПЗ (MS SQL, Oracle DB, MS Exchange, VMware), розміщених на СЗД, з реплікацією на віддалені СЗД та їх відновленням на інших СЗД того ж вендора» (Додаткові вимоги СЗД); 10. «Наявність автономного захисту від програм-вимагачів, що гарантує цілісність записаних файлових ресурсів» (Додаткові вимоги). З огляду на: • вимоги статті 5 Закону України «Про публічні закупівлі» щодо принципів добросовісної конкуренції, недискримінації учасників та відкритості закупівель; • частину 4 статті 22 Закону України «Про публічні закупівлі», що забороняє включення до тендерної документації вимог, які обмежують конкуренцію та призводять до дискримінації учасників; • частину 4 статті 5 Закону, просимо Замовника внести наступні зміни до тендерної документації, а саме у пунктах: 1. Архітектура — кількість одночасних відмов дисків. Чинне формулювання: «СЗД повинен підтримувати можливість виходу з ладу до 3 дисків одночасно». Пропонована редакція: «СЗД повинна підтримувати можливість виходу з ладу не менше 2 дисків одночасно». Обґрунтування: захист від одночасного виходу з ладу двох дисків (RAID-6, RAID-DP, DRAID-6, DRE DP, DDP та аналогічних схем подвійної парності) є загальноприйнятим галузевим стандартом для all-flash NVMe СЗД та забезпечує адекватний рівень відмовостійкості. Triple parity (3 диски одночасно) на ринку block-storage реалізована лише в обмеженій кількості вендорів (, переважна більшість сучасних масивів — Dell PowerStore, Hitachi VSP One, IBM FlashSystem та інші— підтримують саме подвійну парність. Запропонована редакція також усуває суперечність документації з розділом «Накопичувачі». 2. Архітектура — протокол підключення дискових полиць. Чинне формулювання: «Підключення дискових полиць має бути реалізоване за допомогою 100Gb інтерфейсів протоколами RoCE або аналогічних технологій». Пропонована редакція: «Підключення дискових полиць має бути реалізоване інтерфейсами з пропускною здатністю не менше 100 Gb/s за протоколами RoCE, NVMe-oF, NVMe або еквівалентними технологіями, що забезпечують необхідну пропускну здатність та відмовостійкість». Обґрунтування: жорстка прив'язка до конкретного транспортного протоколу (RoCE) не є обґрунтованою з функціональної точки зору. Метою вимоги має бути забезпечення цільової продуктивності back-end-каналу, а не обрання конкретної транспортної реалізації. Поточне формулювання штучно виключає сучасні архітектури з еквівалентною або вищою пропускною здатністю на базі NVMe-oF, NVMe, PCIe-based fabric тощо. 3. Архітектура — логічний поділ на віртуальні системи. Чинне формулювання: «Можливість логічного поділу СЗД на віртуальні з окремими адресами керування». Пропонована редакція: «Можливість логічної ізоляції ресурсів СЗД між незалежними навантаженнями (multi-tenancy) із засобами розмежування доступу, які можуть бути реалізовані технологіями SVM, vStore, Virtual Storage Machines, Storage Containers або еквівалентними засобами виробника». Обґрунтування: чинне формулювання повторює фірмову термінологію NetApp ONTAP (Storage Virtual Machine). Функціонал multi-tenancy реалізований у всіх корпоративних СЗД, проте під різними назвами та з різним рівнем розмежування адрес керування. Формулювання має описувати функціональну мету, а не конкретну реалізацію одного виробника. 4. Встановлені порти СЗД — порти кластерного з'єднання. Чинне формулювання: «Для створення кластера на рівні СЗД повинні використовуватися порти 100Gb по 2 на контролер». Пропонована редакція: «Для організації міжконтролерного з'єднання в межах СЗД та/або кластера повинна використовуватися виділена відмовостійка шина з пропускною здатністю не менше 100 Gb/s на контролер (наприклад, 100GbE, PCIe-based interconnect, NVLink-based interconnect або еквівалентні технології)». Обґрунтування: чинне формулювання вимагає конкретного типу інтерфейсу (Ethernet 100Gb) для cluster interconnect, що є архітектурною специфікою ONTAP-кластерів. Більшість конкурентних рішень використовує виділені PCIe-based або InfiniBand-based шини для міжконтролерної взаємодії з еквівалентною або вищою пропускною здатністю. Вимога має визначати цільові показники продуктивності каналу, а не його конкретну транспортну реалізацію. 5. Встановлені порти СЗД — комплектація кабелями. Чинне формулювання: «Наявність мінімум 8 портів 25Gb iSCSI в комплекті з DAC-кабелями 25GB SFP28-SFP28 Cu, 2м». Пропонована редакція: «Наявність мінімум 8 портів 25Gb iSCSI в комплекті з кабельною інфраструктурою для підключення: 8 шт. DAC-кабелів 25Gb SFP28-SFP28 Cu, 2м, АБО 8 шт. трансиверів SFP28 з оптичними кабелями LC-LC OM4 Duplex 2м». Обґрунтування: тип кабельного підключення (DAC vs оптика) не впливає на функціональні характеристики СЗД, її продуктивність чи сумісність. Обмеження виключно DAC-кабелями створює необґрунтовані переваги для частини виробників, які підтримують встановлення таких кабелів у порти СЗД, та не має технічного обґрунтування. 6. Архітектура — носії для операційної системи. Чинне формулювання: «СЗД не повинна використовувати окремі фізичні носії для зберігання операційної системи». Пропонована редакція: виключити цю вимогу з тендерної документації або змінити на «СЗД повинна забезпечувати завантаження операційної системи з резервованих носіїв без впливу на доступність даних користувача». Обґрунтування: спосіб зберігання операційної системи контролера (на data-дисках, на окремих M.2 NVMe, у NVDIMM тощо) не впливає на функціональні характеристики, продуктивність чи відмовостійкість СЗД для кінцевого користувача. Чинна вимога є архітектурною особливістю окремих виробників, а не функціональною характеристикою. Більшість сучасних корпоративних СЗД (Dell PowerStore, Hitachi VSP One, Huawei OceanStor Dorado) використовує окремі boot-носії з повним резервуванням, що жодним чином не знижує надійність системи. 7. Додаткові вимоги — кількість снапшотів. Чинне формулювання: «…має підтримуватись до 2?10^6 снапшотів на одну систему». Пропонована редакція: «Система має підтримувати не менше 1?10^6 снапшотів на кластер, при цьому створення та зберігання снапшотів не повинно призводити до суттєвого зниження продуктивності СЗД». Обґрунтування: ліміт 2?10^6 (а точніше 2 097 152 = 2^21) снапшотів є характерним саме для NetApp ONTAP. Ліміт у 1?10^6 (1 мільйон) снапшотів на кластер є більш ніж достатнім для покриття типових корпоративних сценаріїв (масове створення точок відновлення, політики retention, ransomware-захист) і водночас не обмежує штучно коло технічно придатних рішень. 8. Додаткові вимоги — гранульовані снапшоти прикладного ПЗ. Чинне формулювання: «Можливість робити гранульовані снапшоти окремого ПЗ (MS SQL, Oracle DB, MS Exchange, VMware), розміщених на СЗД, з реплікацією на віддалені СЗД та їх відновленням на інших СЗД того ж вендора». Пропонована редакція: «Можливість створення консистентних снапшотів типу application-consistent snapshots окремого ПЗ (MS SQL, Oracle DB, MS Exchange, VMware) із засобами реплікації на віддалену СЗД того ж вендора та відновлення з реплікованих знімків». Обґрунтування: чинне формулювання описує фірмовий продукт NetApp SnapCenter, що інтегрується виключно з ONTAP-системами. Функціонал application-aware snapshots реалізовано у всіх провідних виробників СЗД через відповідні фірмові інструменти (Dell AppSync, Hitachi Ops Center Protector, IBM Storage Copy Data Management, Huawei UltraPath/BCManager) або через інтеграцію з backup-рішеннями (Veeam, Commvault, Veritas), які забезпечують функціонально еквівалентний результат. 9. Додаткові вимоги — захист від програм-вимагачів. Чинне формулювання: «Наявність автономного захисту від програм-вимагачів, що гарантує цілісність записаних файлових ресурсів». Пропонована редакція: «Наявність функціоналу захисту від програм-вимагачів, реалізованого засобами СЗД». Обґрунтування: предметом закупівлі є блочна СЗД, що працює з логічними томами (LUN), а не з файловими ресурсами; посилання на «файлові ресурси» є архітектурно неузгодженим з рештою ТЗ. Вимога має бути узагальненою, вимагаючи від виробника наявність механізмів захисту від шифрування/пошкодження даних (наприклад, immutable захист), що може бути реалізовано на блочному рівні. 10. Додаткові вимоги — переміщення холодних даних. Чинне формулювання: «СЗД має підтримувати технологію переміщення холодних даних на інші типи носіїв чи СХД в автоматичному режимі. При цьому повинні переміщатися лише блоки». Пропонована редакція: виключити вимогу з тендерної документації як таку, що не є функціонально обґрунтованою для предмета закупівлі. Обґрунтування: предметом закупівлі є all-NVMe система зберігання даних (виключно з NVMe QLC SSD), де відсутні рівні носіїв з різними характеристиками продуктивності в межах однієї системи. Концепція переміщення «холодних» даних на «повільніший» tier у all-NVMe-конфігурації не має технічного сенсу. Вимога є архітектурно неузгодженою з рештою ТЗ. З огляду на викладене, просимо Замовника: 1. Внести зазначені зміни до технічного завдання тендерної документації з метою забезпечення дотримання принципів недискримінації та добросовісної конкуренції; 2. Опублікувати оновлену редакцію тендерної документації з обґрунтованим продовженням строку подання тендерних пропозицій; 3. У разі незгоди з пропонованими змінами — надати технічне обґрунтування необхідності кожної з оскаржуваних вимог саме у заявленому формулюванні, із зазначенням переліку конкретних моделей провідних виробників (окрім NetApp та його OEM-систем від Lenovo ThinkSystem DM/DG і Fujitsu ETERNUS AX/HX), які, на думку Замовника, відповідають усій сукупності опублікованих технічних вимог. Звертаємо увагу, що збереження оскаржуваних вимог у чинній редакції створює підстави для звернення зацікавлених учасників до Антимонопольного комітету України зі скаргою на дискримінаційні умови тендерної документації відповідно до статті 18 Закону України «Про публічні закупівлі».

Дата оприлюднення звернення: 16.05.2026 12:38

Добрий день, шановний учаснику, дякуємо за запитання. Зміни внесено в ТД та додатково надаємо відповідь на запитання. 2. «Підключення дискових полиць має бути реалізоване за допомогою 100Gb інтерфейсів протоколами RoCE або аналогічних технологій» (Архітектура); Відповідь: На думку замовника протоколи NVMe-oF, NVMe є аналогічними технологіями, що й вказано в даному пункті. Більш висока швидкість передавання даних, у разі надходження таких пропозицій, буде розглядатися як значне покращення. Технічну вимогу залишаємо без змін. 5. «Наявність мінімум 8 портів 25Gb iSCSI в комплекті з DAC-кабелями 25GB SFP28-SFP28 Cu, 2м» (Встановлені порти СЗД); Відповідь: Ми згодні, що тип підключення не впливає на його функціональні характеристики, але заміна DAC-кабелю на оптичне з’єднання веде за собою закупівлю не 8 а 16 трансіверів (зворотні у комутатори, до яких буде підключено СЗД), що, враховуючи невелику відстань між СЗД та комутаторами, необґрунтовано подорожчає й так не дешеве рішення (близько $3136 за 8 DAC-кабелів та $23 160 за 16 трансіверів та 8 оптичних кабелів згідно цін, що взято з HPE Product Bulletin на дану продукцію). Технічну вимогу залишаємо без змін.

Дата оприлюднення відповіді: 19.05.2026 17:26

Звернення за тендером: Серверне, мережеве обладнання та матеріали до нього

Тема: Щодо дискримінаційних технічних вимог до комутаторів

Зміст: Шановний Замовнику! За результатами аналізу технічних вимог до комутаторів ми встановили, що ці технічні умови мають ознаки штучного обмеження конкурентного вибору, та через це порушення принципів добросовісної конкуренції та недискримінації учасників, а саме: 1. серед технічних вимог є такі, які є фірмовою (пропрієтарною) технологією одного виробника, а саме: у вимозі «Функціонал L2: STP/RSTP/MSTP/PVST+/ RPVST+» вказаний протокол PVST+, якій є фірмовим (пропрієтарним) протоколом компанії Cisco; 2. також є вимога до комутаторів щодо необхідності підтримки блоків живлення постійного струму, що, по-перше є характерним для умов використання обладнання в серверних операторів зв’язку, і зовсім нерелевантне для корпоративних ЦОДів, а по-друге, ніяк не узгоджується з вимогами щодо живлення іншого обладнання, що є предметів закупівлі – серверів та СЗД; отже, цілком зрозуміло, що ця вимога попала в ТЗ цієї закупівлі або випадково, при копіюванні, або навмисно як засіб обмежити конкуренцію з використанням необґрунтованих обмежень; 3. у вимозі групи «QoS» серед алгоритмів QoS, які мають підтримуватися, є один тільки WRR (Weighted Round Robin), якій є застарілий, і вже має наступний удосконалений варіант реалізації, відомий під назвою Deficit Round Robin (DRR) або Deficit Weighted Round Robin (DWRR); отже, цілком зрозуміло, що ця вимога попала в ТЗ цієї закупівлі або випадково, при копіюванні, або навмисно як засіб обмежити конкуренцію з використанням необґрунтованих обмежень щодо використання тільки застарілого алгоритму, а не його більш сучасних наступників. З огляду на: • вимоги статті 5 Закону України «Про публічні закупівлі» щодо принципів добросовісної конкуренції, недискримінації учасників та відкритості закупівель; • частину 4 статті 22 Закону України «Про публічні закупівлі», що забороняє включення до тендерної документації вимог, які обмежують конкуренцію та призводять до дискримінації учасників; переконливо просимо Замовника внести наступні зміни до тендерної документації: 1. вилучити з техвимог до комутаторів щодо функціоналу L2 вимогу підтримки пропрієтаних технологій PVST+ та RPVST+, заливши тільки вимоги щодо підтримки стандартних STP/RSTP/MSTP; 2. вилучити з техвимог до комутаторів щодо підтримки варіантів блоків живлення необхідність підтримки блоків живлення постійного струму; 3. додати до переліку алгоритмів QoS, що мають підтримуватися, більш актуальні варіанти реалізації WRR, тобто пропонуємо замінити «QoS: Керування чергами WRR, щонайменше 7 черг на кожен порт» на «QoS: Керування чергами WRR, або DRR, або DWRR, щонайменше 7 черг на кожен порт» Просимо Замовника: 1. Внести зазначені зміни до технічного завдання тендерної документації з метою забезпечення дотримання принципів недискримінації та добросовісної конкуренції; 2. Опублікувати оновлену редакцію тендерної документації з обґрунтованим продовженням строку подання тендерних пропозицій; 3. У разі незгоди з пропонованими змінами — надати технічне обґрунтування необхідності кожної з оскаржуваних вимог саме у заявленому формулюванні, із зазначенням переліку моделей провідних світових виробників (Cisco, Juniper/HPE, NVIDIA, Dell, Arista, Extreme, HPE Aruba), які, на думку Замовника, відповідають усій сукупності опублікованих технічних вимог. Звертаємо увагу, що збереження оскаржуваних вимог у чинній редакції створює підстави для звернення зацікавлених учасників до Антимонопольного комітету України з скаргою на дискримінаційні умови тендерної документації відповідно до статті 18 Закону України «Про публічні закупівлі».

Дата оприлюднення звернення: 19.05.2026 13:28

Добрий день, дякуємо за запитання. Шановний учаснику, надаємо наступну відповідь на поставлене запитання:1. серед технічних вимог є такі, які є фірмовою (пропрієтарною) технологією одного виробника, а саме: у вимозі «Функціонал L2: STP/RSTP/MSTP/PVST+/ RPVST+» вказаний протокол PVST+, якій є фірмовим (пропрієтарним) протоколом компанії Cisco; Відповідь: Шановний учаснику, Замовник не заперечує, що PVST+/Rapid PVST+ історично пов’язані з реалізацією spanning tree у обладнанні Cisco. Водночас сама по собі наявність у технічних вимогах підтримки або сумісності з такими механізмами не свідчить про обмеження конкуренції, оскільки відповідний функціонал або сумісна взаємодія реалізовані в обладнанні різних виробників. Підтримка PVST+/RPVST+ або функціональна взаємодія з мережами, у яких використовуються такі механізми, наявна у рішеннях різних виробників, зокрема: • HPE Aruba / Aruba CX (CX 8325-48Y8C)— підтримує Rapid PVST / RPVST-конфігурацію; • Juniper Networks (EX4650-48Y-AFI) — через VSTP; у документації Juniper зазначено рекомендацію використовувати VSTP разом з RSTP при взаємодії з Cisco Rapid PVST+; • Extreme Networks (7520 - 48YE - 8CE) — у документації прямо зазначена підтримка PVST+ та R-PVST+; • Dell Networking / PowerSwitch / SONiC (S5224F-ON) — документація Dell містить налаштування PVST+ та RPVST і зазначає підтримку PVST+, RPVST та MSTP; • Arista (DCS-7050SX3-24YC4C) — у документації прямо зазначена підтримка RPVST+ • H3C (S6530X-24Y8C) — у документації прямо зазначена підтримка PVST+ та R-PVST+; • також існують рішення інших виробників із режимами взаємодії з Rapid PVST+/RPVST+, наприклад FortiSwitch у відповідних сценаріях міжмережевої взаємодії. Таким чином, вимога не встановлює обов’язку постачання обладнання Cisco або будь-якого іншого конкретного виробника, а визначає необхідний функціональний результат — коректну інтеграцію нового обладнання в існуючу L2-інфраструктуру Замовника. Наявність такої вимоги обумовлена необхідністю збереження працездатності, цілісності та безперервності роботи мережі Замовника, у якій використовуються VLAN, резервовані L2-з’єднання та механізми spanning tree для запобігання мережевим петлям. Відсутність підтримки або сумісності з PVST+/RPVST+ може призвести до некоректної роботи STP-топології, втрати резервування або виникнення ризиків для стабільності мережі. Замовник допускає постачання еквівалентного обладнання різних виробників за умови документального підтвердження підтримки PVST+/RPVST+ або повної функціональної сумісності з ними без втрати працездатності існуючої мережевої інфраструктури. 2. також є вимога до комутаторів щодо необхідності підтримки блоків живлення постійного струму, що, по-перше є характерним для умов використання обладнання в серверних операторів зв’язку, і зовсім нерелевантне для корпоративних ЦОД-ів, а по-друге, ніяк не узгоджується з вимогами щодо живлення іншого обладнання, що є предметів закупівлі – серверів та СЗД; отже, цілком зрозуміло, що ця вимога попала в ТЗ цієї закупівлі або випадково, при копіюванні, або навмисно як засіб обмежити конкуренцію з використанням необґрунтованих обмежень; Відповідь: Шановний учаснику, аналіз сучасного ринку мережевого обладнання корпоративного класу свідчить, що даний функціонал є індустріальним стандартом і реалізований у лінійках більшості провідних світових виробників. Зокрема, технічним вимогам тендерної документації (включаючи можливість встановлення БЖ постійного струму) повністю відповідає обладнання таких вендорів та моделей: • Dell (модель S5224F-ON); • HPE Aruba (модель CX 8325-48Y8C); • Juniper (модель EX4650-48Y-AFI); • Extreme Networks (модель 7520-48YE-8CE); • H3C (модель S6530X-24Y8C); • Arista (модель DCS-7050SX3-24YC4C). Всі зазначені пристрої мають конструкцію з двома відсіками для блоків живлення з підтримкою гарячої заміни (Hot-Swap) та дозволяють гнучко комплектувати комутатор БЖ потрібного типу (AC або DC). Наявність на ринку щонайменше 6 (шести) альтернативних моделей від різних незалежних виробників, які повністю задовольняють вимоги Замовника, беззаперечно доводить відсутність ознак штучного обмеження конкуренції чи дискримінації учасників. Учасники мають повну свободу вибору обладнання для формування своєї тендерної пропозиції. . 3. у вимозі групи «QoS» серед алгоритмів QoS, які мають підтримуватися, є один тільки WRR (Weighted Round Robin), якій є застарілий, і вже має наступний удосконалений варіант реалізації, відомий під назвою Deficit Round Robin (DRR) або Deficit Weighted Round Robin (DWRR); отже, цілком зрозуміло, що ця вимога попала в ТЗ цієї закупівлі або випадково, при копіюванні, або навмисно як засіб обмежити конкуренцію з використанням необґрунтованих обмежень щодо використання тільки застарілого алгоритму, а не його більш сучасних наступників. Відповідь: Шановний учаснику, вказаний Вами алгоритм Deficit Round Robin (DRR) або Deficit Weighted Round Robin (DWRR) є не єдиним удосконаленим алгоритмом, що використовують сучасні комутатори та не завжди вендор вказує який саме удосконалений алгоритм він використовує, наприклад: Dell S5224F-ON - Weighted Round Robin (WRR); HPE Aruba Networking CX 8325-48Y8C - Deficit Weighted Round Robin (DWRR); Juniper/HPE EX4650-48Y-AFI - Shaped-Deficit Weighted Round-Robin (SDWRR); Extreme 7520 - 48YE - 8CE - Weighted Round Robin (WRR); H3C S6530X-24Y8C - Weighted Round Robin (WRR), Strict Priority + Weighted Round Robin (SP+WRR); Arista DCS-7050SX3-24YC4C - Weighted Round Robin (WRR); Cisco C9300X-24Y - Shaped Round Robin (SRR); Nvidia SN3420 / HPE M-Series SN3420M - scheduling-DWRR and Strict Priority. З огляду на таку кількість удосконалених алгоритмів Round Robin була сформульована вимога щодо підтримки алгоритму WRR (Weighted Round Robin), яка є базованою на стандартах мережевої індустрії та не забороняє використання більш сучасних алгоритмів. Вона визначає мінімально необхідний функціонал для сумісності з поточною політикою якості обслуговування (QoS) Замовника. Наявність у обладнання додаткових або новіших алгоритмів (DRR/DWRR) не заважає йому виконувати базову вимогу щодо підтримки WRR. Твердження Учасника про «навмисне обмеження» є лише його суб'єктивним оціночним судженням. Досконалість чи новіша версія алгоритму (DWRR) не означає, що Замовник зобов'язаний змінювати свою архітектуру під технологічні тренди, які вважає кращими конкретний Учасник.

Дата оприлюднення відповіді: 22.05.2026 15:30

Звернення за тендером: Серверне, мережеве обладнання та матеріали до нього

Тема: вимоги згідно Додатку 2

Зміст: Шановний замовнику! У пункті 1 Розділу 3 Тендерної документації міститься вимога щодо надання інформації про маркування, протоколи випробувань або сертифікати, що підтверджують відповідність предмета закупівлі встановленим вимогам згідно з Додатком 2 до тендерної документації. З метою належного оформлення тендерної пропозиції та запобігання її відхиленню просимо надати роз’яснення: Чи вимагається від учасника подання окремого супровідного документа (зокрема порівняльної таблиці технічних характеристик, таблиці відповідності або довідки у довільній формі), що підтверджує відповідність вимогам Додатка 2? Чи буде достатнім підтвердженням відповідності вимогам Додатка 2 подання самого Додатка 2 у складі пропозиції, підписаного уповноваженою особою учасника та скріпленого печаткою підприємства (за наявності) та/або накладенням КЕП?

Дата оприлюднення звернення: 21.05.2026 10:56

Доброго дня, шановний учаснику, дякуємо за запитання! Керуючись вимогами Закону України «Про публічні закупівлі» та Особливостей, затверджених постановою КМУ від 12.10.2022 № 1178 (із змінами), на Ваш запит повідомляємо: Щодо форми надання інформації: Тендерна документація замовника не містить вимоги щодо подання інформації виключно у вигляді окремої порівняльної таблиці чи довідки довільної форми. Учасник може надати інформацію у будь-якій зручній для нього формі (у вигляді окремого документа, таблиці відповідності або шляхом внесення відомостей безпосередньо до тексту Додатка 2). Щодо достатності лише підписаного Додатка 2: Подання тексту Додатка 2 у незмінній редакції замовника (шаблону), підписаного КЕП/УЕП, не є достатнім підтвердженням відповідності. Для забезпечення можливості співставлення пропозиції учасника з документами від виробника (авторизаційним листом), учасник в обов'язковому порядку має зазначити в складі своєї пропозиції конкретні технічні та якісні характеристики пропонованого товару (зазначити конкретного виробника, торгову марку, модель та чіткі цифрові параметри замість виразів «не менше», «або еквівалент»). Таким чином, учасник має право заповнити Додаток 2, вписавши туди конкретні характеристики та назви свого обладнання, або винести ці дані в окрему порівняльну таблицю чи довідку.

Дата оприлюднення відповіді: 22.05.2026 15:48

Звернення за тендером: Серверне, мережеве обладнання та матеріали до нього

Тема: Щодо комутаторів

Зміст: Просимо Замовника виключити вимогу щодо MTBF ?20 років з технічної специфікації або замінити її на збільшений строк сервісної підтримки виробника, з наступних причин: 1. MTBF не є публічно стандартизованим параметром у сегменті комутаторів ЦОД. Більшість провідних світових виробників мережевого обладнання data-center класу (Juniper Networks / HPE, Cisco, Arista, NVIDIA, Dell, Fortinet, Extreme Networks, Nokia) не публікують значення MTBF у відкритих datasheet на свої комутатори серій ЦОД. Тому, якщо у відкритому datasheet на комутатори виробництва ЄС\США показник MTBF відсутній, це не свідчить про низьку надійність обладнання, а є галузевою практикою — MTBF є внутрішньою інженерною метрикою. Відповідно, строге дотримання цієї вимоги у вигляді запису в datasheet штучно обмежує коло потенційних учасників до 1-2 виробників (фактично — лише до тих, чия методика розрахунку MTBF орієнтована на маркетинговий показник в специфікації), що суперечить принципам відкритої конкуренції та рівних умов для учасників закупівлі. 2. Надійність вже забезпечена іншими вимогами специфікації Технічна специфікація вже містить повний комплекс вимог до апаратної надійності, які покривають всі аспекти безперервної роботи: • Два блоки живлення з гарячою заміною; • Вентилятори з гарячою заміною; • Можливість встановлення БЖ різного типу живлення (AC або DC); • Підтримка побудови відмовостійкої логічної системи з не менше ніж 2 комутаторів (MC-LAG/vPC/VC); • Збереження працездатності та передачі трафіку при відмові одного з пристроїв; • Робочий діапазон 0°C to +40°C. Цей комплекс вимог технічно гарантує відмовостійкість рішення на рівні системи, що значно важливіше для критичних DC-середовищ, ніж паспортний MTBF окремого пристрою. 3. Сервісна підтримка виробника є реальним і вимірюваним гарантом надійності У сучасній практиці закупівлі DC-обладнання показником надійності та своєчасності відновлення сервісу є не MTBF, а рівень підтримки виробника (Care/Support contract). Зокрема: • MTTR (Mean Time To Repair) — реальний час відновлення; • SLA-параметри сервісу: NBD (Next Business Day), 4HR (4-hour onsite), 24x7x4; • Термін підтримки (3/5 років); • RMA-процедура (Return Material Authorization) у виробника. Якщо у тендерній документації передбачена окрема вимога до рівня сервісної підтримки виробника на 3 роки з гарантованими часовими параметрами реакції, ця вимога повністю заміщує MTBF як критерій надійності і є більш практично значущою. Також можна розширити сервісну підтримку для комутаторів до 5 років, без зміни кошторису проєкту. 4. Невідповідність специфікаціям до серверного та СЗД обладнання Звертаємо увагу Замовника, що в аналогічних технічних специфікаціях на серверне обладнання та системи зберігання даних (СЗД), які також є критичною інфраструктурою центру обробки даних, вимога до MTBF з кількісним порогом, як правило, відсутня — натомість використовуються вимоги до: • Надмірності (redundancy) компонентів; • Hot-swap здатності; • Рівня сервісної підтримки виробника (Pro Support / Mission Critical / тощо). Така диференціація вимог між класами обладнання (серверне обладнання — без MTBF, мережеве — з MTBF) не має об'єктивного технічного обґрунтування, оскільки: • Сервери та СЗД мають більшу кількість рухомих частин (HDD, SSD, вентилятори різних рівнів, рейд-контролери); • Сервери та СЗД зазвичай мають нижчий розрахунковий MTBF, ніж мережеві комутатори (через більшу складність і кількість компонентів); • Рівень критичності для безперервності бізнес-процесів у серверів/СЗД та мережевих комутаторів — порівнянний. Отже, вимога MTBF до комутаторів за відсутності аналогічної вимоги до серверів/СЗД є непослідовною і потребує гармонізації з вимогами до інших товарів. Просимо Замовника виключити пункт «Середній час напрацювання на відмову (MTBF), не менше 20 років» з технічної специфікації, оскільки надійність забезпечується іншими вимогами специфікації та вимогами до сервісної підтримки.

Дата оприлюднення звернення: 21.05.2026 16:54

Добрий день. Шановний Учаснику у Додатку 2 до тендерної документації для комутаторів зазначено вимогу: «Середній час напрацювання на відмову (MTBF), не менше 20 років». Ця вимога встановлена як показник розрахункової надійності обладнання центру обробки даних та не є довільною або унікальною характеристикою окремого виробника. MTBF є загальновживаним інженерним показником прогнозування надійності електронного та мережевого обладнання, який може розраховуватися за визнаними міжнародними методиками, зокрема Telcordia SR-332 або MIL-HDBK-217. Тому твердження Учасника про те, що MTBF не є стандартизованим або належним технічним параметром для комутаторів, є технічно необґрунтованим. Відсутність такого показника у відкритому короткому описі товару не свідчить про неможливість його розрахунку або підтвердження виробником. При цьому вимога щодо MTBF не замінює гарантійне та сервісне обслуговування, а доповнює його, оскільки гарантія визначає порядок реагування у разі несправності, тоді як MTBF характеризує очікуваний рівень надійності обладнання на етапі його експлуатації. Наявність блоків живлення та вентиляторів з гарячою заміною, підтримка відмовостійкої логічної системи з двох комутаторів та сервісна підтримка 36 місяців 9x5 NBD вирішують питання відновлення роботи та обслуговування. Водночас MTBF характеризує саме розрахункову надійність окремого пристрою. Це різні показники, тому наявність сервісної підтримки не є підставою для виключення вимоги щодо MTBF. Також звертаємо увагу, що Додаток 2 до тендерної документації не встановлює вимоги, що значення MTBF має бути зазначене виключно у відкритому datasheet. Учасник може підтвердити відповідність вимозі документом виробника або іншим офіційним підтвердженням, якщо це передбачено виробником для відповідної моделі обладнання. Аргумент Учасника про те, що вимога нібито обмежує конкуренцію до 1–2 виробників, не підтверджений належним технічним аналізом. Сам факт відсутності показника MTBF у відкритому описі окремої моделі не доводить, що виробник не може підтвердити цей показник офіційною документацією або що вимога є унікальною для одного виробника. Заміна MTBF на збільшений строк сервісної підтримки не є рівнозначною. Строк підтримки визначає період обслуговування обладнання, а MTBF — розрахунковий показник надійності самого пристрою. Для Замовника важливі обидва аспекти: як надійність обладнання так й можливість його гарантійного обслуговування.

Дата оприлюднення відповіді: 24.05.2026 12:49

Звернення за тендером: Серверне, мережеве обладнання та матеріали до нього

Тема: Щодо вимоги «Пропуск пересилання пакетів»

Зміст: Просимо Замовника зменшити вимогу до forwarding rate з ?1300 Mpps до ?1200 Mpps з наступних технічних причин: 1. Поріг 1300 Mpps декларується для синтетичного тестового сценарію, який не відображає реальний DC-трафік Показник forwarding rate, декларований виробниками мережевого обладнання, вимірюється у тестовому сценарії line-rate forwarding 64-байтними пакетами (RFC 2544 wire-speed test). Цей синтетичний сценарій не відображає реальних умов експлуатації центру обробки даних: Підтвердження від виробників мережевого обладнання: • Arista Networks у своїй офіційній документації «DANZ Monitoring Fabric Verified Scale Guide» прямо вказує: «IMIX is a 7:4:1 distribution of 64, 570, and 1518-byte Ethernet-encapsulated packets, leading to a 353-byte packet size average.» Джерело: https://www.arista.com/en/sg-dmf/sg-dmf-danz-monitoring-fabric-verified-scale • Cisco Systems у поточних офіційних datasheet серії Catalyst 8200/8300/8500 (актуальні документи виробника) використовує визначення: «IMIX is average packet size of 352 Bytes packet size.» Джерела: • Cisco Catalyst 8200: https://www.cisco.com/c/en/us/products/collateral/routers/catalyst-8200-series-edge-platforms/nb-06-cat8200-series-edge-plat-ds-cte-en.html • Cisco Catalyst 8300: https://www.cisco.com/c/en/us/products/collateral/routers/catalyst-8300-series-edge-platforms/datasheet-c78-744088.html • Cisco Catalyst 8500: https://www.cisco.com/c/en/us/products/collateral/routers/catalyst-8500-series-edge-platforms/datasheet-c78-744089.html • Cisco Performance Analysis (Miercom) у документі «Performance Analysis: Cisco Integrated Services Router» зафіксував: «With this IMIX packet distribution, the average packet size for our tests was 378 bytes (including Layer-2 overhead).» Джерело: https://www.cisco.com/c/dam/en/us/products/collateral/routers/4000-series-integrated-services-routers-isr/miercom-isr4k-report.pdf Підтвердження від академічних досліджень DC-трафіку: • ACM SIGCOMM IMC — «Network Traffic Characteristics of Data Centers in the Wild»: «Packet sizes exhibit a bimodal pattern, with most packet sizes clustering around either 200 Bytes and 1400 Bytes.» • Microsoft Research — «Understanding Network Failures in Data Centers» (SIGCOMM 2011): «Average size of lost packets is 423 bytes. Prior measurement study on data center network traffic observed that packet sizes tend to be bimodal with modes around 200B and 1,400B.» 2. Реальна потреба у forwarding rate для конфігурації ТЗ При портовій конфігурації, що передбачена ТЗ (24?25G + 4?100G = 1000 Gbps simplex) та реальному розподілі трафіку 350-740 байт середнього розміру пакету, фактична потреба у forwarding rate становить: • При середньому пакеті 352 байти (Cisco IMIX, Arista IMIX): ~330 Mpps • При середньому пакеті 423 байти (Microsoft Research DC measurement): ~280 Mpps • При середньому пакеті 740 байт (сучасний DC mix): ~170 Mpps Це означає, що навіть показник 1200 Mpps має кратний запас (у 3-7 разів) відносно реальної експлуатаційної потреби, не кажучи вже про мінімальну різницю між 1200 і 1300 Mpps. 3. Поріг 1300 Mpps штучно обмежує конкуренцію Поріг 1300 Mpps з мінімальним розривом у 100 Mpps відносно 1200 Mpps формально виключає всю Cisco Nexus 9300-FX3 серію — поточну серію Cisco з 25G/100G портами, повною підтримкою VXLAN EVPN, MACsec, SyncE та PTP. Cisco Nexus 9300-FX3: • Повністю покриває всі функціональні вимоги ТЗ; • Є визнаним світовим лідером ринку DC-комутаторів за версією Gartner Magic Quadrant. Це штучно обмежує конкуренцію без об'єктивного технічного обґрунтування, оскільки різниця 100 Mpps (?8%) не впливає на реальну експлуатаційну продуктивність DC-середовища. 4. Реальна продуктивність визначається не Mpps, а архітектурними параметрами Для DC-сценаріїв експлуатації значно важливішими є: • Buffer size (40 MB у Cisco Nexus 9300-FX3) — для уникнення packet loss під час мікробурстів; • Latency (близько 1 мікросекунди) — критично для AI/ML, RoCE, HFT-навантажень; • VOQ архітектура з підтримкою ECN/PFC для lossless transport; • Intelligent Buffer Management (Dynamic Packet Prioritization, AFD/ETRAP). Усі ці параметри значно більше впливають на реальну продуктивність DC-мережі, ніж паспортний показник Mpps, виміряний на 64-байтних пакетах у синтетичному тесті. 5. Відсутність обґрунтування саме порогу 1300 Mpps Згідно з принципами публічних закупівель та формування технічної специфікації, кожен кількісний поріг має мати об'єктивне технічне обґрунтування. Просимо Замовника пояснити, який саме DC-сценарій вимагає forwarding rate саме 1300 Mpps, а не, наприклад, 1200 Mpps або 1500 Mpps. У разі відсутності такого обґрунтування, поріг є довільним і має бути приведений у відповідність до галузевих стандартних значень. Просимо Замовника зменшити вимогу пункту «Пропуск пересилання пакетів» з «не менше 1300 Мп/с» до «не менше 1200 Мп/с».

Дата оприлюднення звернення: 21.05.2026 18:38

Добрий день. Шановний Учаснику у вимогах до комутаторів Додатку 2 до тендерної документації зазначено показник «Пропуск пересилання пакетів: не менше 1300 Mpps». Цей показник є паспортною характеристикою комутатора й використовується для оцінки запасу продуктивності обладнання. Замовник не виходить лише з усередненого профілю трафіку, оскільки в реальній експлуатації мережева інфраструктура Замовника містить різні типи навантаження: службовий, керуючий, інфраструктурний (реплікація, віртуалізація) та прикладний трафік з різним розміром пакетів. Запропоноване зменшення показника з 1300 Mpps до 1200 Mpps не додає Замовнику жодної функціональної переваги, а лише знижує мінімальний рівень продуктивності обладнання, яке може бути запропоноване Учасниками. Для комутаторів, що закуповуються для довготривалої роботи у серверному середовищі, наявність запасу продуктивності є обґрунтованою. На підтвердження ствердження про штучне обмеження конкуренції Учасник у якості приклада вказує лише одну серію комутаторів Cisco Nexus 9300-FX3, що обмежується по параметру Пропуск пересилання пакетів, який у даній лінійці дорівнює 1200 Mpps. Натомість на ринку наявні комутатори різних виробників, які відповідають або перевищують показник 1300 Mpps, зокрема HPE Aruba CX 8325-48Y8C (2000 Mpps), Juniper EX4650-48Y-AFI (1490 Mpps), H3C S6530X-24Y8C (1920 Mpps), Arista DCS-7050SX3-24YC4C (2000 Mpps) та інші моделі відповідного класу. Остаточна відповідність конкретної моделі підтверджується учасником у складі тендерної пропозиції.

Дата оприлюднення відповіді: 24.05.2026 13:52

Звернення за тендером: Серверне, мережеве обладнання та матеріали до нього

Тема: Щодо інтерфейсу управління комутаторами

Зміст: Просимо Замовника переглянути три взаємопов'язані пункти технічної специфікації, що стосуються інтерфейсу управління комутаторами, з огляду на сучасні архітектурні принципи побудови мереж центрів обробки даних. Архітектурний принцип комутаторів ЦОД — розподіл функцій управління: Архітектура датацентр-класу комутаторів провідних світових виробників (Cisco, Juniper Networks, Dell Technologies, HPE, Arista, NVIDIA) передбачає, що кожен пристрій має власну консоль управління (CLI). Це забезпечує: • Гнучкість конфігурування на рівні окремого пристрою; • Відмовостійкість (відмова одного комутатора не впливає на доступність решти); • Незалежність площини управління (management plane); • Відповідність принципам безпеки (segmentation of duties). Архітектура DC-комутаторів принципово відрізняється від stackable campus-комутаторів (на кшталт Cisco Catalyst, Aruba 2930, Extreme серії 5520), де «єдина логічна точка управління» реалізується через stacking-кабелі та об'єднання у віртуальний chassis. У DC-сегменті стекування у класичному сенсі майже не використовується — натомість застосовуються технології розподіленого керування з активною узгодженою конфігурацією на кожному пристрої: • Cisco vPC (Virtual Port Channel); • Juniper VC (Virtual Chassis) / MC-LAG / ESI-LAG; • Dell VLT (Virtual Link Trunking); • HPE Aruba VSX (Virtual Switching Extension); • ALE Unified Virtual Chassis. Централізоване управління у сучасних DC завжди реалізується через зовнішні системи: Це є галузевим стандартом і єдиним способом забезпечити справжню масштабованість, графічну топологію, централізовані оновлення ПЗ та інтегровану роботу з конфігураціями десятків і сотень пристроїв: • Cisco — Nexus Dashboard Fabric Controller (NDFC), Cisco Intersight; • Juniper Networks — Apstra Data Center Director, Junos Space, Mist AI for Data Center; • Dell Technologies — SmartFabric Director, OpenManage Enterprise — Network; • HPE Aruba — Aruba Central, Fabric Composer, NetEdit; • ALE — OmniVista 2500 Network Management System; • Arista — CloudVision Portal (CVP); • NVIDIA — NetQ. Локальний Web UI у DC-сегменті є застарілою практикою: У більшості провідних виробників датацентр-комутаторів локальний Web UI обмежено реалізований або відсутній через об'єктивні причини: • Обмежений функціонал — локальний Web UI не може забезпечити повноцінне керування fabric-середовищем (VXLAN EVPN, MP-BGP, multi-pod, multi-site); • Ризики безпеки — наявність локального HTTP/HTTPS-сервісу на кожному пристрої збільшує attack surface (CVE-вразливості, потенціал для credential theft), а провідні виробники у своїй власній офіційній документації прямо інструктує адміністраторів вимикати локальний HTTP/HTTPS web UI на комутаторах для підвищення безпеки - «If you want to disable the web user interface (UI) and use only the command line interface (CLI) to manage the switch in your network... HTTP and HTTPS can be disabled... If remote command line access is needed, make sure the box next to SSH Service is checked.» Джерело: https://www.cisco.com/c/en/us/support/docs/smb/switches/Cisco-Business-Switching/kmgmt3607-disabling-http-https-services-in-switches.html • Відсутність автоматизації — Web UI не підтримує DevOps-практики (Ansible, Terraform, Python-скрипти, NETCONF/RESTCONF/gNMI); • Невідповідність DC-практикам — реальне керування DC-fabric завжди здійснюється через CLI + автоматизовані системи, ніколи через локальний Web UI на кожному пристрої. Зокрема: • Cisco NX-OS — Web UI на самому комутаторі відсутній; всі задачі через CLI, NX-API, NETCONF або централізовано через NDFC; • Juniper Junos OS — є базовий J-Web, проте у DC-сценаріях не використовується; всі задачі через CLI або централізовано через Apstra/Mist; • Dell SmartFabric OS10 — Web UI обмежений у функціоналі; основне керування через CLI або SmartFabric Director; • NVIDIA Cumulus / SONiC — Web UI на пристрої відсутній взагалі за архітектурою. Тому, наявність цих вимог штучно обмежують конкуренцію. Вимоги «єдина логічна точка управління», «Наявність Веб інтерфейсу» — є надмірними та не відповідають сучасним практикам побудови DC-середовища. Вони штучно обмежують конкуренцію, оскільки жоден провідний виробник DC-комутаторів не реалізує таку функціональність у самому комутаторі без зовнішньої системи керування. Просимо виключити вимогу «єдину логічну точку управління або централізоване управління групою пристроїв» Обґрунтування: Архітектура DC-комутаторів передбачає, що кожен пристрій має власну консоль управління. «Єдина логічна точка управління» у класичному сенсі (stack-master, virtual chassis з master/backup) не реалізується сучасними DC-комутаторами (Cisco, Dell, HPE, Arista). Натомість централізоване управління групою пристроїв реалізується через зовнішні системи керування того ж виробника, що вже передбачено окремим пунктом специфікації («Можливість управління і моніторингу з централізованої системи управління того ж виробника»). Відмовостійкість і кооперативна робота двох комутаторів забезпечується технологіями MC-LAG / vPC / VLT / VSX / Virtual Chassis (вже передбачено цією ж вимогою у наступних підпунктах), які не вимагають «єдиної логічної точки управління», а використовують peer-to-peer координацію. Просимо змінити вимогу «Наявність Веб інтерфейсу, командного рядка» та викласти у такій редакції: «Наявність командного рядка та підтримка централізованого GUI-керування через зовнішні системи керування того ж виробника.» Обґрунтування: У більшості провідних виробників DC-комутаторів локальний Web UI не використовується через обмежений функціонал, ризики безпеки та невідповідність DevOps-практикам сучасного DC. Натомість стандартним і best-practice підходом є: • CLI на пристрої для конфігурування та діагностики (відповідає security best practices: NIST SP 800-53, CIS Benchmarks); • Централізований GUI через зовнішню систему керування виробника для управління топологією, конфігураціями, оновленнями та моніторингом. Запропонована редакція зберігає принцип наявності GUI-керування, але приводить його у відповідність до сучасних DC-практик, де GUI реалізується централізовано через NMS, а не локально на кожному пристрої. Запропоновані зміни: • Не знижують функціональних можливостей рішення; • Усувають дублювання вимог; • Розширюють коло учасників за рахунок включення провідних світових виробників DC-сегменту (Cisco, Juniper, Dell, HPE, ALE, Arista, NVIDIA); • Забезпечують відповідність сучасним архітектурним практикам та стандартам безпеки.

Дата оприлюднення звернення: 21.05.2026 19:55

Добрий день. Шановний Учаснику у Додатку 2 до тендерної документації не встановлено обов’язкової вимоги щодо класичного стекування комутаторів або використання конкретної архітектури об’єднання пристроїв. Вимога сформульована альтернативно: «єдина логічна точка управління або централізоване управління групою пристроїв». Отже, допускається як логічне об’єднання комутаторів, так і централізоване управління групою пристроїв. Крім того, у цьому ж пункті передбачено MC-LAG або еквівалент, тобто Додаток 2 до тендерної документації не обмежує учасників однією конкретною технологією. Учасник може запропонувати реалізацію виробника, яка забезпечує агрегування каналів між різними пристроями, роботу в режимі Active-Active або Active-Standby та збереження передачі трафіку при відмові одного з комутаторів. Щодо вимоги «наявність веб-інтерфейсу, командного рядка» зазначаємо, що вона не означає обов’язку керувати всією мережевою інфраструктурою Замовника виключно через локальний веб-інтерфейс кожного комутатора. Йдеться про наявність додаткового штатного інструменту доступу до керування або моніторингу поряд із командним рядком. Окремо Додатком 2 до тендерної документації вже передбачено можливість управління і моніторингу з централізованої системи управління виробника, а також функціонал управління групами пристроїв, побудови графічної топології, централізованого оновлення програмного забезпечення та роботи з конфігураціями пристроїв. Запропонована Учасником редакція фактично прибирає вимогу щодо веб-інтерфейсу як одного зі штатних способів доступу та залишає лише командний рядок і зовнішню систему управління. Така зміна не розширює функціональність для Замовника, а навпаки звужує набір доступних корисних інструментів управління.

Дата оприлюднення відповіді: 24.05.2026 14:09

Звернення за тендером: Серверне, мережеве обладнання та матеріали до нього

Тема: щодо підтримки протоколів RIPv2 та RIPng

Зміст: Просимо Замовника виключити вимогу щодо підтримки протоколів RIPv2 та RIPng з технічної специфікації з наступних технічних та практичних причин: 1. RIP є застарілим протоколом, виключеним зі стандартного функціоналу сучасних DC-операційних систем Routing Information Protocol (RIPv1, RIPv2, RIPng) — це distance-vector протокол маршрутизації, розроблений у 1980-х роках для невеликих enterprise-мереж. Через свої принципові обмеження (максимум 15 hops, повільна конвергенція 30-180 секунд, full-table updates кожні 30 секунд, відсутність ефективної підтримки великих топологій) RIP не використовується в сучасних центрах обробки даних уже понад 15 років. Провідні виробники мережевого обладнання data-center класу усвідомлено виключили RIP зі стандартного функціоналу своїх сучасних DC-операційних систем як архаїчний та невідповідний вимогам сучасних DC-середовищ. Зокрема: Cisco NX-OS (Nexus 9000 серія) – підтримує RIPv2 для IPv4, не підтримує RIPng Dell SmartFabric OS10 – не підтримує RIPv2, не підтримує RIPng Nokia SR Linux - не підтримує RIPv2, не підтримує RIPng Extreme SLX-OS - не підтримує RIPv2, не підтримує RIPng Arista EOS - не підтримує RIPv2, не підтримує RIPng Натомість сучасні DC-операційні системи реалізують маршрутизацію на основі: • OSPFv2 + OSPFv3 — для IPv4 + IPv6; • BGP + MP-BGP — для underlay/overlay у VXLAN EVPN fabric; • IS-IS — для масштабованих SPB/EVPN-fabric топологій; • Static routing з ECMP — для простих топологій. Ці протоколи повністю покривають весь функціонал, який раніше виконував RIP, але з значно кращою конвергенцією, масштабованістю, безпекою та підтримкою IPv6. 2. Цей пункт ТЗ суперечить іншим вимогам специфікації Технічна специфікація містить вимоги, які чітко свідчать про орієнтацію рішення на сучасну DC-архітектуру: • VXLAN L2/L3 комутація — overlay-технологія сучасних DC; • VXLAN VTEP — endpoint для overlay-фабрики; • Ethernet Virtual Private Network (EVPN) — control plane для VXLAN, який архітектурно базується на MP-BGP, а не на RIP; • PIM-SM і PIM-SSM — multicast routing protocols; • OSPFv2 і OSPFv3 — основні IGP протоколи; • BGP — основний протокол для EVPN. Поєднання вимог «EVPN + RIPv2/RIPng» є технічно несумісним за призначенням: EVPN-VXLAN — це сучасна архітектура 2015+ років, тоді як RIP — це протокол з обмеженим використанням навіть для невеликих enterprise-мереж 1990-х. Жоден замовник у реальному DC-проєкті не використовує RIP паралельно з EVPN-VXLAN, оскільки це функціонально неможливо і концептуально суперечливе. Наявність обох цих вимог в одному ТЗ свідчить про технічну непослідовність специфікації. 3. Вимога штучно обмежує конкуренцію до 1-2 виробників Поєднання вимог «RIPv2 + RIPng» — це характерна ознака специфікації, написаної під конкретного виробника (а саме — Huawei CloudEngine або H3C, де RIPv2 та RIPng залишаються у стандартному стеку як спадщина enterprise-орієнтованих NOS). Це означає, що жорстке дотримання цієї вимоги виключає з конкурсу провідних світових виробників (Cisco, Dell, Nokia, Extreme, Arista, Fortinet), що суттєво обмежує конкуренцію та принципи рівних умов для учасників закупівлі. 4. Виключення RIPv2/RIPng не знижує функціональні можливості рішення Усі задачі маршрутизації, які теоретично могли б виконуватись через RIPv2/RIPng у даному DC-сценарії, повністю покриваються іншими протоколами, які вже вимагаються специфікацією: Порівняння сучасної реалізації мережевих задач із застарілою реалізацією через RIP: IPv4 IGP маршрутизація: у сучасній реалізації (за ТЗ) використовуються OSPFv2 та BGP, тоді як застаріла реалізація передбачала RIPv2. IPv6 IGP маршрутизація: для сучасних рішень застосовуються OSPFv3 та MP-BGP, а в застарілих варіантах використовувався RIPng. Static routing: у сучасній реалізації повністю передбачено технічним завданням (ТЗ), тоді як у застарілій схемі цей пункт відсутній. Inter-VRF / overlay routing: сучасний підхід базується на EVPN-VXLAN з MP-BGP, в той час як у застарілій архітектурі це неможливо реалізувати через обмеження RIP. Multicast: для сучасних мереж використовуються протоколи PIM-SM та PIM-SSM, тоді як у застарілій реалізації через RIP це зробити неможливо. Тобто видалення RIPv2/RIPng не призведе до жодної функціональної прогалини в рішенні. Натомість збереження цієї вимоги необґрунтовано обмежує коло учасників і не приносить замовнику жодної реальної технічної переваги. 5. Сумісність з вимогами безпеки та сучасними DC-стандартами Слід зазначити, що RIPv2 за сучасними стандартами безпеки вважається небезпечним протоколом для DC-середовища: • Слаба автентифікація (тільки MD5); • Вразливість до route injection атак; • Відсутність ефективного захисту від route poisoning. Сучасні DC-стандарти (NIST SP 800-53, ISO 27001, CIS Benchmarks) рекомендують уникати використання RIP у критичних інфраструктурах, віддаючи перевагу OSPF/BGP з повноцінною автентифікацією. Пропозиція Просимо Замовника виключити пункт «RIPv2 і RIPng» з технічної специфікації з огляду на: • Технічну застарілість протоколу для DC-середовища; • Концептуальну несумісність з іншими вимогами специфікації (EVPN, VXLAN); • Штучне обмеження конкуренції до 1-2 виробників; • Повне покриття функціональних потреб іншими протоколами, що вже передбачені специфікацією (OSPFv2/v3, BGP); • Відповідність сучасним DC-стандартам та best practices. АБО Замінити пункт «RIPv2 і RIPng» на: «Підтримка щонайменше двох протоколів динамічної IGP-маршрутизації для IPv4 та IPv6 (з переліку: OSPFv2/OSPFv3, RIPv2/RIPng, IS-IS, EIGRP, BGP).» Це збереже принцип підтримки повного стеку маршрутизації, але дозволить виробникам використовувати сучасні рекомендовані протоколи замість застарілих.

Дата оприлюднення звернення: 21.05.2026 20:26

Добрий день. Шановний Учаснику у вимогах до комутаторів Додатку 2 до тендерної документації передбачено підтримку RIPv2 і RIPng як одного з елементів функціоналу L3. При цьому Додаток 2 також містить вимоги щодо OSPFv2/OSPFv3, BGP, ECMP, VRRP, VXLAN, EVPN, PIM-SM/PIM-SSM та інших протоколів. Тобто вимога щодо RIPv2/RIPng не визначає архітектуру мережевої інфраструктури Замовника як таку, що повинна будуватися саме на RIP. RIPv2 та RIPng не є закритими або пропрієтарними технологіями окремого виробника. Це відкриті стандартизовані протоколи маршрутизації: RIPv2 описаний у RFC 2453, RIPng — у RFC 2080. Той факт, що в сучасних мережах частіше використовуються OSPF, BGP або EVPN/VXLAN, не робить саму підтримку RIPv2/RIPng дискримінаційною вимогою. Вимога встановлена для забезпечення сумісності обладнання з різними сегментами мережевої інфраструктури Замовника, у тому числі з існуючими ділянками, що використовують протоколи маршрутизації RIPv2 та RIPng. Наявність підтримки RIPv2/RIPng не означає, що Замовник планує використовувати ці протоколи як основні. Окремо Замовник звертає увагу, що запропонована Учасником редакція не є рівнозначною чинній вимозі. У тендерній документації вже окремо передбачено підтримку OSPFv2/OSPFv3, BGP, ECMP, VRRP, VXLAN, EVPN, PIM-SM/PIM-SSM та інших функцій L3. Тому заміна вимоги RIPv2/RIPng на загальне формулювання щодо “щонайменше двох протоколів” фактично не розширює функціонал, а прибирає конкретну вимогу сумісності, яка необхідна Замовнику. Крім того, запропонована Учасником редакція містить внутрішню неточність, оскільки до переліку “динамічної IGP-маршрутизації” включено BGP, який за своєю природою не є IGP-протоколом. Також формулювання “щонайменше двох протоколів для IPv4 та IPv6” не визначає, які саме протоколи мають забезпечувати IPv4- та IPv6-маршрутизацію, що знижує визначеність технічної специфікації. Посилання Учасника на те, що RIPv2/RIPng не є основними протоколами сучасних центрів обробки даних, не спростовує можливості Замовника вимагати їх підтримку як додатковий елемент сумісності. Наявність підтримки RIPv2/RIPng не означає обов’язку використовувати ці протоколи як основні у продуктивній EVPN/VXLAN-архітектурі. Слід також зазначити, що на ринку наявні комутатори різних виробників, які відповідають даній вимозі, зокрема HPE Aruba CX 8325-48Y8C, Juniper EX4650-48Y-AFI, H3C S6530X-24Y8C, Arista DCS-7050SX3-24YC4C.

Дата оприлюднення відповіді: 24.05.2026 16:44

Звернення за тендером: Серверне, мережеве обладнання та матеріали до нього

Тема: Сервер віртуалізації

Зміст: Шановний Замовнику! У технічних вимогах до серверного обладнання зазначено вимогу щодо підтримки сервером не менше 3-х GPU-прискорювачів, однак при цьому у тендерній документації відсутні будь-які вимоги до самих GPU, а саме: тип GPU; сфера застосування (AI/HPC/VDI/CAD тощо); мінімальний обсяг пам’яті; інтерфейс підключення; необхідна продуктивність; допустиме енергоспоживання (TDP). Відсутність зазначених характеристик унеможливлює коректний підбір серверного обладнання та створює передумови для штучного обмеження кола потенційних учасників та виробників, оскільки на нашу думку тільки один виробник має сервер який підтримує 3 GPU у форм факторі 1U, також зазаначаємо підтримка 3-х GPU суттєво впливає на: конструктив серверу; систему охолодження; кількість та потужність блоків живлення; форм-фактор та внутрішню архітектуру серверу. Додатково звертаємо увагу, що більшість сучасних серверних GPU-прискорювачів мають TDP від 300W і більше. У зв’язку з викладеним просимо: Надати уточнення щодо необхідних GPU-прискорювачів та їх характеристик. Вказати мінімально необхідний та/або допустимий рівень TDP GPU. У разі відсутності фактичної потреби у GPU — виключити вимогу щодо підтримки не менше 3-х GPU як таку, що не має технічного обґрунтування. Або якщо ця вимога є суттєвою і необхідною для проєкту, просимо вказати, які виробники і які моделі серверів відповідають вимогам цього пункту в технічній документації.

Дата оприлюднення звернення: 21.05.2026 21:38

Добрий день. Шановний Учаснику у Додатку 2 до тендерної документації зазначено вимогу щодо підтримки встановлення не менше трьох GPU-карт. При цьому постачання самих GPU-карт у складі серверного обладнання не передбачене. Відповідно, відсутність вимог до типу, обсягу пам’яті, продуктивності або енергоспоживання GPU не є недоліком документації, оскільки GPU-карти не є предметом постачання в межах цієї закупівлі. Твердження Учасника про те, що таку вимогу може виконати лише один виробник, не підтверджується. Підтримка до трьох GPU-карт у серверах форм-фактора 1U наявна у кількох незалежних виробників, зокрема у відповідних конфігураціях: • Dell PowerEdge R670 — до трьох NVIDIA L4 24 GB 72 W single-width GPU; • Lenovo ThinkSystem SR630 V4 — до трьох NVIDIA L4 24 GB PCIe GPU; • HPE ProLiant Compute DL360 Gen12 — до трьох low-profile single-wide GPU з максимальною потужністю 75 W; • Fujitsu PRIMERGY RX2530 M8 — до трьох NVIDIA L4 GPU. Посилання Учасника на GPU з TDP від 300 W і більше не стосується встановленої вимоги. Додаток 2 до тендерної документації не вимагає підтримки трьох високопотужних GPU та не визначає конкретний клас прискорювачів. Йдеться саме про конструктивну можливість встановлення не менше трьох GPU-карт як запас для подальшої модернізації серверів для майбутнього використання у якості платформи віртуалізації робочих столів.

Дата оприлюднення відповіді: 24.05.2026 16:45

Звернення за тендером: Серверне, мережеве обладнання та матеріали до нього

Тема: По єдиній системі моніторингу серверів/СЗД/комутаторів

Зміст: Шановний Замовнику! У технічних вимогах зазначено: «Підтримка сервером єдиної системи моніторингу та управління ІТ-парком обладнання (сервери, СЗД, комутатори, не менше 1000 пристроїв), доступною для встановлення у форматі готового для розгортання образу віртуальної машини із встановленим ПЗ управління» та «Можливість керування не менше 100 пристроїв в рамках окремої групи управління». Формально вимога подана як функціональна, однак її виконання можливе переважно в межах закритої екосистеми виробника, архітектурні ознаки якого простежуються в інших пунктах технічного завдання. Це обмежує можливість подання еквівалентних мультивендорних рішень, у яких сервери, системи зберігання даних та мережеве обладнання інтегруються через стандартні протоколи та відкриті інтерфейси. Вважаємо, що дана вимога до програмного забезпечення не є функціонально нейтральною та фактично орієнтує закупівлю на рішення одного виробника, вибір якого неодноразово простежується через інші технічні вимоги документації. У сучасних ІТ-інфраструктурах сервери, системи зберігання даних та мережеве обладнання часто є мультивендорними та інтегруються між собою через стандартні протоколи та інтерфейси: Redfish; IPMI; SNMP; Syslog; REST API; CLI; telemetry; або еквівалентні механізми. Також звертаємо увагу, що предметом закупівлі передбачено постачання лише: 4 серверів; 1 СЗД; 2 комутаторів, при цьому вимагається система моніторингу та управління на 1000 пристроїв та окремі групи на 100 пристроїв, що виглядає технічно та економічно надлишковим для даної закупівлі. Просимо: Надати обґрунтування необхідності вимоги щодо підтримки централізованого управління не менше 1000 пристроїв. (вказати повний перелік, щоб була можливість запропонувати правильне рішення) Уточнити, чи допускається використання штатних засобів моніторингу кожного виробника із підтримкою інтеграції через стандартні протоколи. Викласти вимогу у наступній редакції: «Кожен компонент комплексу повинен мати штатні засоби керування та моніторингу. Допускається інтеграція через стандартні протоколи та інтерфейси, зокрема Redfish, IPMI, SNMP, Syslog, REST API, CLI, telemetry або еквівалентні механізми виробника».

Дата оприлюднення звернення: 21.05.2026 21:39

В відповідь на запитання до процедури публічних закупівель «По єдиній системі моніторингу серверів/СЗД/комутаторів» від 21.05.2026 21:39 щодо оголошення UA-2026-05-12-010741-a «Серверне, мережеве обладнання та матеріали до нього», пропоную наступний проєкт відповіді: Добрий день. Шановний Учаснику у Додатку 2 до тендерної документації передбачено, що сервер має підтримувати єдину систему моніторингу та управління ІТ-парком обладнання, зокрема серверами, системами збереження даних та комутаторами, з підтримкою не менше 1000 пристроїв, а також можливістю керування не менше 100 пристроями в межах окремої групи управління. Вимога щодо підтримки не менше 1000 пристроїв не означає, що в межах цієї закупівлі постачається саме 1000 одиниць обладнання. Це вимога до класу та масштабованості системи управління. Обладнання, що закуповується, має використовуватися не як ізольований комплект, а як складова частина поточної ІТ-інфраструктури Замовника з можливістю подальшого розширення. Окремо Замовник звертає увагу, що запропонована Учасником редакція істотно змінює зміст вимоги. У чинній редакції тендерної документації йдеться про єдину систему моніторингу та управління ІТ-парком обладнання, доступну у форматі готового до розгортання образу віртуальної машини із встановленим програмним забезпеченням управління, з підтримкою не менше 1000 пристроїв та можливістю керування не менше 100 пристроями в межах окремої групи управління. Натомість Учасник пропонує замінити цю вимогу на наявність окремих штатних засобів керування та моніторингу кожного компонента комплексу. Такий підхід не є рівнозначним, оскільки набір окремих інструментів різних виробників не забезпечує того самого рівня централізованого управління, єдиної інвентаризації, групових політик, централізованого оновлення мікрокодів, застосування шаблонів налаштувань та керування життєвим циклом обладнання. Крім того, формулювання «допускається інтеграція через стандартні протоколи та інтерфейси» не встановлює обов’язку забезпечити фактично працюючу єдину систему управління. Протоколи Redfish, IPMI, SNMP, Syslog, REST API, CLI або telemetry є засобами обміну даними чи доступу до обладнання, але самі по собі не є повноцінною системою централізованого моніторингу та управління ІТ-парком. Також запропонована редакція повністю прибирає кількісні показники масштабованості — підтримку не менше 1000 пристроїв та керування не менше 100 пристроями в межах окремої групи. Це знижує визначеність технічної специфікації та не дає Замовнику можливості перевірити, чи відповідає запропоноване рішення необхідному класу масштабування. Посилання Учасника на те, що в межах цієї закупівлі постачається 4 сервери, 1 система збереження даних та 2 комутатори, не спростовує об’єктивної потреби Замовника у масштабованій системі управління. Обладнання яке планується до закупівлі Замовником буде експлуатуватися не як ізольований комплект, а як складова частина поточної ІТ-інфраструктури Замовника, з урахуванням подальшого розвитку, централізованого адміністрування та уніфікації процесів обслуговування. Вимога не містить посилання на конкретну торговельну марку або конкретну модель програмного забезпечення. Подібний підхід до централізованого управління реалізований у різних виробників серверного та інфраструктурного обладнання, зокрема у рішеннях HPE OneView, Dell OpenManage Enterprise, Lenovo XClarity Administrator, Cisco Intersight та інших системах відповідного класу. З наданих Учасником пояснень Замовником не вбачається достатніх підстав вважати, що встановлена вимога є унікальною для одного виробника або об’єктивно обмежує участь інших учасників. Разом з тим запропонована Учасником редакція є менш визначеною та не забезпечує підтвердження того самого рівня централізованого управління, автоматизації, інвентаризації та масштабованості, який передбачено тендерною документацією.

Дата оприлюднення відповіді: 24.05.2026 16:46

Звернення за тендером: Серверне, мережеве обладнання та матеріали до нього

Тема: Система збереження даних

Зміст: Шановний Замовнику! Зауважуємо, що вимога щодо конкретної кількості, типу та номіналу накопичувачів у складі СЗД може суттєво обмежувати участь виробників, які використовують власні флеш-модулі, DirectFlash-модулі або іншу архітектуру all-flash систем. Для Замовника функціонально важливими є: корисна ємність; продуктивність; відмовостійкість; масштабованість; гарантійна та сервісна підтримка, а не конкретна кількість фізичних SSD певного номіналу. За нашою технічною оцінкою, сукупність зазначених характеристик фактично відповідає конкретній моделі/архітектурі тільки одного виробника та суттєво звужує коло можливих еквівалентних рішень. Відповідно до вимог Закону України «Про публічні закупівлі», технічна специфікація не повинна містити посилання на конкретну торговельну марку, фірму, патент, конструкцію, тип предмета закупівлі, джерело походження або виробника. Якщо таке посилання є необхідним, воно має бути обґрунтованим, а специфікація повинна містити вираз «або еквівалент». Також під час дії воєнного стану закупівлі здійснюються з урахуванням Особливостей, затверджених постановою КМУ №1178 від 12.10.2022, які регулюють порядок проведення публічних закупівель у цей період. З метою забезпечення добросовісної конкуренції, недискримінації учасників та можливості запропонувати еквівалентні рішення різних виробників, просимо уточнити та/або внести зміни до технічних вимог та викласти їх у наступній редакції: «СЗД повинна бути побудована на all-flash NVMe архітектурі з використанням корпоративних флеш-накопичувачів / флеш-модулів TLC, QLC або еквівалентної технології виробника. Корисна ємність СЗД після застосування механізмів захисту даних повинна становити не менше 197 TiB. Конкретна кількість, тип та номінал флеш-накопичувачів / модулів визначаються архітектурою виробника.» Також просимо уточнити та надати технічне обґрунтування необхідності встановлення саме зазначених показників read/write та IOPS. У разі якщо Замовник вважає наведені значення критично необхідними саме у зазначених параметрах, просимо надати технічне обґрунтування таких вимог, оскільки їх сукупність може відповідати конкретному виробнику/моделі та обмежувати можливість участі з еквівалентними рішеннями інших виробників.Просимо повідомити, яким чином вимога щодо конкретної кількості та номіналу SSD/NVMe накопичувачів впливає на функціональні характеристики предмета закупівлі, якщо кінцевими критично важливими параметрами для Замовника є корисна ємність, продуктивність, відмовостійкість та гарантійна підтримка СЗД. На нашу думку, фіксація конкретної кількості та типу накопичувачів без можливості застосування альтернативної архітектури виробника може свідчити про штучне обмеження конкуренції та звуження кола потенційних учасників. Якщо ця вимога є суттєвою і необхідною для проєкту, просимо вказати, які виробники і які моделі СЗД відповідають вимогам цього пункту в технічній документації.

Дата оприлюднення звернення: 21.05.2026 21:40

Добрий день. Шановний Учаснику вимога щодо кількості, типу та номіналу накопичувачів у складі системи збереження даних встановлена не як посилання на конкретного виробника, а для визначення мінімальної конфігурації обладнання, яку можна об’єктивно порівняти між пропозиціями Учасників. Учасник пропонує залишити лише загальну вимогу до корисної ємності та передати кількість, тип і номінал накопичувачів на розсуд виробника. Такий підхід, на думку Замовника, зменшує визначеність вимог: різні учасники зможуть запропонувати рішення, які формально мають однакову корисну ємність, але істотно відрізняються за щільністю, запасом масштабування, ресурсом, схемою відновлення після відмови накопичувачів та вартістю подальшої підтримки. Вимога щодо використання NVMe QLC SSD пов’язана з потребою Замовника отримати систему збереження даних з високою щільністю, достатньою корисною ємністю, підтримкою сучасних протоколів доступу та можливістю подальшого розширення без заміни всієї системи. Додаток 2 до тендерної документації не містить посилання на конкретну торговельну марку або конкретну модель накопичувача. Щодо продуктивності зазначаємо, що Додатком 2 до тендерної документації передбачено надання офіційного сайзингу, який підтверджує необхідну продуктивність запропонованої конфігурації. Тобто відповідність має підтверджуватися не декларативно, а офіційним розрахунком. Твердження Учасника про те, що сукупність вимог відповідає лише одному виробнику, не підтверджене технічним порівнянням або документами виробників. На ринку наявні системи збереження даних різних виробників, які у відповідних конфігураціях підтримують NVMe-накопичувачі, QLC-носії, масштабування ємності та продуктивності, зокрема NetApp AFF/ASA C-Series, Dell PowerStore, HPE Alletra Storage MP та інші рішення відповідного класу.

Дата оприлюднення відповіді: 24.05.2026 16:50

Звернення за лотом: №1, Серверне, мережеве обладнання та матеріали до нього

Тема: Вимога щодо RAID з 2 дисками parity

Зміст: Шановний Замовнику! У технічних вимогах зазначено: «Загальний корисний дисковий простір має бути не менше 197 TiB в режимі RAID з 2 дисками парності для швидкого відновлення даних у разі виходу з ладу». Звертаємо увагу, що сучасні системи зберігання даних enterprise-рівня можуть використовувати власні механізми захисту даних, які не є класичним RAID з двома parity-дисками, але при цьому забезпечують еквівалентний або вищий рівень відмовостійкості, продуктивності та швидкості відновлення даних. За нашою технічною оцінкою, вимога щодо конкретної реалізації механізму RAID може фактично відповідати архітектурі окремих виробників та суттєво звужувати можливість запропонувати еквівалентні рішення інших виробників, які використовують власні механізми data protection, distributed parity, erasure coding, DirectFlash protection або інші еквівалентні технології. Відповідно до вимог Закону України «Про публічні закупівлі», технічна специфікація не повинна містити вимог, що обмежують конкуренцію або призводять до дискримінації учасників. Також під час дії воєнного стану закупівлі здійснюються з урахуванням Особливостей, затверджених постановою КМУ №1178 від 12.10.2022. З метою забезпечення добросовісної конкуренції, недискримінації учасників та можливості запропонувати еквівалентні рішення різних виробників, просимо викласти вимогу у наступній редакції: «Загальний корисний дисковий простір має бути не менше 197 TiB після застосування штатного механізму захисту даних виробника. СЗД повинна забезпечувати захист даних у разі відмови не менше двох накопичувачів / флеш-модулів або еквівалентний рівень відмовостійкості, підтверджений виробником.»

Дата оприлюднення звернення: 21.05.2026 21:40

Добрий день. Шановний Учаснику у Додатку 2 до тендерної документації передбачено, що загальний корисний дисковий простір має бути не менше 197 TiB в режимі RAID з 2 дисками парності для швидкого відновлення даних у разі виходу з ладу. Зазначена вимога встановлена не лише як вимога до обсягу, а як вимога до підтвердженого корисного простору після застосування визначеного рівня захисту даних. Замовник бере до уваги, що виробники систем збереження даних можуть використовувати різні внутрішні механізми захисту даних. Водночас це не позбавляє Замовника права встановити конкретний мінімальний рівень захисту та порядок перевірки корисної ємності, який відповідає потребам Замовника. Запропонована Учасником редакція замінює визначену Замовником вимогу загальним формулюванням про «штатний механізм захисту даних виробника» та «еквівалентний рівень відмовостійкості». Таке формулювання є менш визначеним, оскільки не встановлює єдиного критерію розрахунку корисної ємності та може допускати різне тлумачення того, який саме рівень захисту даних вважається еквівалентним. Відповідно до пункту 3 частини другої статті 22 та частини першої статті 23 Закону України «Про публічні закупівлі» Замовник має право визначати необхідні технічні, якісні та функціональні характеристики предмета закупівлі. З наданих Учасником аргументів Замовник не вбачається, що встановлена вимога є унікальною для одного виробника або об’єктивно унеможливлює участь інших Учасників.

Дата оприлюднення відповіді: 24.05.2026 16:51

Звернення за лотом: №1, Серверне, мережеве обладнання та матеріали до нього

Тема: HA-пари, 2–8 нод та 4 пар високої доступності

Зміст: Шановний Замовнику! У технічних вимогах зазначено: «Можливість розширення СХД на одну HA-пару: не менше 48 накопичувачів NVMe QLC SSD»; «Можливість розширення СЗД: не менше ніж 1,4 ПБ сирої ємності на одну HA-пару»; «Можливість масштабування SAN: 2–8 нод, 4 пари високої доступності»; «Максимальна сира ємність кластера не менше 5,6 ПБ». Звертаємо увагу, що використання термінів «HA-пара», «2–8 нод», «4 пари високої доступності» фактично описує конкретну архітектуру окремих виробників СЗД та може суттєво обмежувати можливість участі інших виробників, які реалізують механізми масштабування та відмовостійкості іншим способом. Сучасні enterprise СЗД можуть забезпечувати: масштабування ємності; масштабування продуктивності; безперервність доступу до даних; відмовостійкість; non-disruptive expansion та upgrade, за допомогою різних архітектурних підходів: масштабування контролерів; active-active архітектури; clustered storage; federated management; distributed architecture; replication; scale-up / scale-out механізмів; або інших штатних технологій виробника. За нашою технічною оцінкою, сукупність зазначених вимог може відповідати архітектурі конкретного виробника та суттєво звужувати коло можливих еквівалентних рішень інших виробників. Відповідно до вимог Закону України «Про публічні закупівлі», технічна специфікація не повинна містити дискримінаційних вимог або вимог, що обмежують конкуренцію. Також під час дії воєнного стану закупівлі здійснюються з урахуванням Особливостей, затверджених постановою КМУ №1178 від 12.10.2022. З метою забезпечення добросовісної конкуренції, недискримінації учасників та можливості запропонувати еквівалентні рішення різних виробників, просимо викласти вимоги у наступній редакції: «СЗД повинна підтримувати масштабування ємності та/або продуктивності без зупинки доступу до даних шляхом додавання накопичувачів / флеш-модулів / полиць, модернізації контролерів, додавання систем або іншими штатними механізмами виробника. Масштабування повинно забезпечувати можливість подальшого розширення системи без переривання роботи сервісів.»

Дата оприлюднення звернення: 21.05.2026 21:41

Добрий день. Шановний Учаснику у Додатку 2 до тендерної документації вимоги щодо розширення на одну пару високої доступності, кількості накопичувачів, сирої ємності та масштабування кластера встановлені для визначення мінімального запасу подальшого розвитку системи збереження даних. Ці показники потрібні не для опису конкретного виробника, а для того, щоб Замовник отримав систему, яка може розширюватися без заміни всієї платформи та без переривання доступу до даних. Терміни «пара високої доступності», «нода» та «кластер» у цьому випадку використовуються як опис логічних одиниць масштабування, а не як посилання на конкретну торговельну марку або модель. Замовник звертає увагу, що запропонована Учасником редакція істотно змінює зміст вимог. У чинній редакції тендерної документації встановлені конкретні та перевірювані показники масштабування: не менше 48 накопичувачів NVMe QLC SSD на одну пару високої доступності, не менше 1,4 ПБ сирої ємності на одну пару високої доступності, масштабування SAN 2–8 нод / 4 пари високої доступності та максимальна сира ємність кластера не менше 5,6 ПБ. Натомість запропонована Учасником редакція не містить жодного з цих кількісних показників та замінює їх загальним формулюванням про масштабування шляхом додавання накопичувачів, полиць, модернізації контролерів, додавання систем або іншими штатними механізмами виробника. Такий підхід не дає Замовнику можливості перевірити, чи має запропонована система необхідний запас ємності, кількості накопичувачів, кількості вузлів та кластерного розширення. Крім того, формулювання «масштабування ємності та/або продуктивності» є менш визначеним, ніж вимоги тендерної документації, оскільки допускає наявність лише одного з цих видів масштабування. Для Замовника важливим є не загальна декларація про можливість розширення, а підтверджена здатність системи досягти встановлених мінімальних показників подальшого розвитку. Твердження Учасника про орієнтацію вимог на одного виробника не підтверджене. На ринку наявні системи збереження даних різних виробників, які у відповідних конфігураціях підтримують кластерне масштабування, збільшення кількості накопичувачів та розширення сирої ємності, зокрема NetApp AFF/ASA, Dell PowerStore/PowerMax, HPE Alletra / Primera та інші рішення відповідного класу. З наданих Учасником аргументів Замовником не вбачається, що зазначені вимоги є унікальними для одного виробника або об’єктивно унеможливлюють участь інших учасників. Водночас запропонована Учасником редакція не забезпечує того самого рівня визначеності, перевірюваності, масштабування, ємності та запасу розвитку системи збереження даних.

Дата оприлюднення відповіді: 24.05.2026 16:53

Звернення за тендером: Серверне, мережеве обладнання та матеріали до нього

Тема: Вимога щодо виділеної міжконтролерної шини 100 Gb/s на контролер

Зміст: Шановний Замовнику! У технічних вимогах зазначено: «Для організації міжконтролерного з'єднання в межах СЗД та/або кластера повинна використовуватися виділена відмовостійка шина з пропускною здатністю не менше 100 Gb/s на контролер, наприклад 100GbE, PCIe-based interconnect, NVLink-based interconnect або еквівалентні технології.» Звертаємо увагу, що внутрішня архітектура міжконтролерної взаємодії є технічною реалізацією конкретного виробника та зазвичай не є відкритою характеристикою, яка стандартизовано декларується всіма виробниками СЗД. Не всі виробники розкривають або описують backend/interconnect саме у вигляді «100 Gb/s на контролер», при цьому їх рішення можуть забезпечувати еквівалентний або вищий рівень: продуктивності; відмовостійкості; синхронізації контролерів; доступності даних; роботи без єдиної точки відмови. За нашою технічною оцінкою, вимога щодо конкретної реалізації міжконтролерної шини та фіксованого значення bandwidth може відповідати архітектурі окремих виробників та суттєво звужувати коло можливих еквівалентних рішень інших виробників. Відповідно до вимог Закону України «Про публічні закупівлі», технічна специфікація не повинна містити дискримінаційних вимог або вимог, що обмежують конкуренцію. Також під час дії воєнного стану закупівлі здійснюються з урахуванням Особливостей, затверджених постановою КМУ №1178 від 12.10.2022. Для Замовника функціонально важливими є: відмовостійкість системи; відсутність єдиної точки відмови; гарантована продуктивність; безперервний доступ до даних, а не конкретна реалізація внутрішньої backend/interconnect архітектури. З метою забезпечення добросовісної конкуренції, недискримінації учасників та можливості запропонувати еквівалентні рішення різних виробників, просимо викласти вимогу у наступній редакції: «СЗД повинна мати відмовостійку двоконтролерну або кластерну архітектуру без єдиної точки відмови, що забезпечує заявлену продуктивність та доступність даних. Технічна реалізація міжконтролерної взаємодії визначається архітектурою виробника.»

Дата оприлюднення звернення: 21.05.2026 21:42

Добрий день. Шановний Учаснику у Додатку 2 до тендерної документації передбачено, що для організації міжконтролерного з’єднання в межах СЗД та/або кластера повинна використовуватися виділена відмовостійка шина з пропускною здатністю не менше 100 Gb/s на контролер, з можливістю використання 100GbE, PCIe-based interconnect, NVLink-based interconnect або еквівалентних технологій. Тобто вимога не прив’язує Учасника до одного конкретного способу реалізації міжконтролерної взаємодії. Учасник може запропонувати іншу технологію виробника, якщо вона забезпечує встановлений рівень пропускної здатності та відмовостійкості. Замовник звертає увагу, що запропонована Учасником редакція істотно змінює зміст вимоги. У чинній редакції тендерної документації встановлено не лише загальну вимогу до відмовостійкої архітектури, а конкретний мінімальний технічний рівень міжконтролерної взаємодії: виділена відмовостійка шина з пропускною здатністю не менше 100 Gb/s на контролер із можливістю використання 100GbE, PCIe-based interconnect, NVLink-based interconnect або еквівалентних технологій. Натомість формулювання Учасника «технічна реалізація міжконтролерної взаємодії визначається архітектурою виробника» фактично усуває вимоги щодо виділеного характеру шини, мінімальної пропускної здатності та показника саме на один контролер. За такої редакції будь-який штатний механізм виробника міг би вважатися достатнім, навіть якщо він не забезпечує необхідний Замовнику запас продуктивності, масштабування та передбачуваності роботи системи. Крім того, формулювання «забезпечує заявлену продуктивність» є менш визначеним, оскільки не встановлює, яка саме продуктивність має бути забезпечена, у якій конфігурації, при якому рівні масштабування та яким документом вона підтверджується. Це ускладнює об’єктивну перевірку відповідності пропозицій та може дозволити постачання рішення з нижчим рівнем міжконтролерної взаємодії. Посилання Учасника на те, що окремі виробники не завжди розкривають внутрішню архітектуру міжконтролерної взаємодії у відкритих матеріалах, саме по собі не підтверджує дискримінаційність вимоги. Відповідність може підтверджуватися офіційною технічною документацією, специфікацією запропонованої конфігурації або іншим належним підтвердженням виробника. З наданих Учасником аргументів Замовник не вбачає, що вимога щодо виділеної відмовостійкої шини з пропускною здатністю не менше 100 Gb/s на контролер є унікальною для одного виробника або об’єктивно унеможливлює участь інших учасників. Водночас запропонована Учасником редакція не забезпечує того самого рівня визначеності, перевірюваності, продуктивності та відмовостійкості міжконтролерної взаємодії.

Дата оприлюднення відповіді: 24.05.2026 16:55

Звернення за лотом: №1, Серверне, мережеве обладнання та матеріали до нього

Тема: підключення дискових полиць через 100Gb RoCE

Зміст: Шановний Замовнику! У технічних вимогах зазначено: «Підключення дискових полиць має бути реалізоване за допомогою 100Gb інтерфейсів протоколами RoCE або аналогічних технологій.» Звертаємо увагу, що підключення дискових полиць / модулів розширення є внутрішньою архітектурною реалізацією конкретного виробника СЗД. Сучасні enterprise СЗД можуть використовувати різні технології backend connectivity та scale-out/scale-up розширення, зокрема: NVMe expansion fabric; PCIe-based interconnect; SAS backend; Ethernet fabric; InfiniBand; proprietary backend fabric; або інші штатні механізми виробника. При цьому забезпечується: безперервний доступ до даних; масштабування системи; відмовостійкість; заявлена продуктивність; non-disruptive expansion. За нашою технічною оцінкою, прив’язка саме до «100Gb RoCE» або аналогічного конкретного типу interconnect може відповідати архітектурі окремих виробників та суттєво звужувати коло можливих еквівалентних рішень інших виробників. Відповідно до вимог Закону України «Про публічні закупівлі», технічна специфікація не повинна містити дискримінаційних вимог або вимог, що обмежують конкуренцію. Також під час дії воєнного стану закупівлі здійснюються з урахуванням Особливостей, затверджених постановою КМУ №1178 від 12.10.2022. Для Замовника функціонально важливими є: можливість масштабування; відмовостійкість; стабільна робота СЗД; відсутність переривання доступу до даних; забезпечення заявленої продуктивності, а не конкретна реалізація backend connectivity між контролерами та полицями розширення. З метою забезпечення добросовісної конкуренції, недискримінації учасників та можливості запропонувати еквівалентні рішення різних виробників, просимо викласти вимогу у наступній редакції: «Підключення додаткових полиць / модулів розширення повинно здійснюватися штатними засобами виробника без переривання доступу до даних та із забезпеченням заявленої продуктивності.»

Дата оприлюднення звернення: 21.05.2026 21:42

Добрий день. Шановний Учаснику у Додатку 2 до тендерної документації передбачено, що підключення дискових полиць має бути реалізоване за допомогою 100Gb інтерфейсів протоколами RoCE або аналогічних технологій. Отже, вимога не обмежується виключно RoCE та вже передбачає можливість застосування будь якої технології з перелічених Учасником, за умови забезпечення відповідного технічного рівня. RoCE / RoCEv2 не є закритою технологією окремого виробника. Це відкрита стандартизована технологія RDMA over Converged Ethernet, яка використовується у сучасному мережевому обладнанні, адаптерах та системах збереження даних різних виробників. Тому сама згадка RoCE не може вважатися ознакою прив’язки до одного виробника. Вимога щодо 100Gb інтерфейсів встановлена для забезпечення належної пропускної здатності між системою збереження даних та дисковими полицями, роботи з NVMe-накопичувачами, подальшого масштабування, відмовостійкості та безперервного доступу до даних. Для Замовника важливо отримати не лише формальну можливість підключення полиць, а підтверджений мінімальний рівень такого підключення. Запропонована Учасником редакція «штатними засобами виробника без переривання доступу до даних та із забезпеченням заявленої продуктивності» істотно змінює зміст вимоги, оскільки не містить жодного мінімального показника пропускної здатності. Сам факт того, що певний механізм є штатним для виробника, не підтверджує його відповідність рівню 100Gb інтерфейсів або аналогічних технологій. Крім того, формулювання «із забезпеченням заявленої продуктивності» є менш визначеним, оскільки не встановлює, яка саме продуктивність має бути забезпечена, у якій конфігурації, після якого обсягу розширення та яким документом це підтверджується. Така редакція ускладнює об’єктивну перевірку відповідності пропозицій та може дозволити постачання рішення з нижчим запасом масштабування. Також запропонована Учасником редакція замінює конкретне поняття «дискові полиці» ширшим формулюванням «додаткові полиці / модулі розширення», що може охоплювати різні архітектурні елементи та не гарантує того самого рівня підключення саме дискової підсистеми. Відповідно до пункту 3 частини другої статті 22 та частини першої статті 23 Закону України «Про публічні закупівлі» Замовник має право визначати необхідні технічні, якісні та функціональні характеристики предмета закупівлі. З наданих Учасником аргументів Замовником не вбачається, що вимога щодо підключення дискових полиць за допомогою 100Gb інтерфейсів протоколами RoCE або аналогічних технологій є унікальною для одного виробника або об’єктивно унеможливлює участь інших Учасників. З огляду на викладене, підстави для внесення змін до тендерної документації відсутні, а вимога щодо підключення дискових полиць за допомогою 100Gb інтерфейсів протоколами RoCE або аналогічних технологій залишається без змін.

Дата оприлюднення відповіді: 24.05.2026 16:56

Звернення за лотом: №1, Серверне, мережеве обладнання та матеріали до нього

Тема: 1?10^6 snapshots

Зміст: Шановний Замовнику! У технічних вимогах зазначено: «Система повинна мати можливість створення snapshots, що не впливає на продуктивність СЗД. При цьому має підтримуватись до 1?10^6 snapshots на одну систему.» Звертаємо увагу, що вимога щодо підтримки саме 1 000 000 snapshots може бути характерною для архітектури окремих виробників СЗД та не завжди відображає фактичну експлуатаційну потребу Замовника. Сучасні системи зберігання даних можуть реалізовувати механізми: snapshots; point-in-time copies; immutable copies; redirect-on-write; copy-on-write; metadata-based protection; або інші еквівалентні механізми захищених копій, при цьому забезпечуючи: мінімальний вплив на продуктивність; швидке відновлення даних; захист від логічних помилок та ransomware; ефективне використання ємності. За нашою технічною оцінкою, вимога щодо підтримки саме 1?10^6 snapshots може відповідати архітектурі конкретного виробника та суттєво звужувати коло можливих еквівалентних рішень інших виробників. Відповідно до вимог Закону України «Про публічні закупівлі», технічна специфікація не повинна містити дискримінаційних вимог або вимог, що обмежують конкуренцію. Також під час дії воєнного стану закупівлі здійснюються з урахуванням Особливостей, затверджених постановою КМУ №1178 від 12.10.2022. Для Замовника функціонально важливими є: наявність механізму point-in-time копій; мінімальний вплив на продуктивність; можливість швидкого відновлення даних; відмовостійкість та безпечне зберігання копій, а не конкретна максимальна кількість snapshots, яка є архітектурною особливістю окремих виробників. У зв’язку з викладеним просимо викласти вимогу у наступній редакції: «Система повинна підтримувати створення snapshots / point-in-time копій без суттєвого впливу на продуктивність СЗД. Максимальна кількість snapshots / копій повинна відповідати архітектурі виробника та підтверджуватися офіційною документацією або листом виробника.» Альтернативно, у разі необхідності збереження кількісного показника: «Система повинна підтримувати не менше 100 000 snapshots / point-in-time копій або еквівалентний механізм захищених копій, підтверджений виробником.» Також просимо уточнити, яким чином вимога щодо підтримки саме 1 000 000 snapshots пов’язана із фактичними експлуатаційними потребами предмета закупівлі та надати технічне обґрунтування необхідності встановлення саме такого значення.

Дата оприлюднення звернення: 21.05.2026 21:42

Добрий день. Шановний Учаснику у Додатку 2 до тендерної документації передбачено, що система збереження даних повинна мати можливість створення знімків без впливу на продуктивність системи, з підтримкою до 1?10^6 знімків на одну систему. Зазначений показник встановлений не як поточна щоденна потреба Замовника у створенні саме такої кількості знімків, а як вимога до граничних можливостей системи. Для Замовника важливо, щоб система мала достатній запас масштабування з урахуванням кількості томів, прикладних систем, політик захисту даних, частоти створення знімків та подальшого розвитку інфраструктури. Замовник звертає увагу, що запропонована Учасником редакція істотно змінює зміст вимоги. У чинній редакції тендерної документації встановлено конкретний та перевірюваний кількісний показник — підтримка до 1?10^6 знімків на одну систему. Натомість формулювання Учасника про те, що максимальна кількість знімків або копій повинна «відповідати архітектурі виробника», фактично усуває мінімальний кількісний критерій та робить вимогу залежною від будь-якого штатного обмеження конкретного виробника. Такий підхід не є рівнозначним вимозі тендерної документації, оскільки дозволяє запропонувати систему з істотно меншим запасом масштабування, якщо така кількість копій передбачена архітектурою виробника. При цьому Замовник не зможе об’єктивно порівняти пропозиції за єдиним мінімальним показником. Крім того, поняття «snapshots», «point-in-time копії», «immutable copies» або «еквівалентний механізм захищених копій» не завжди є тотожними за технічною реалізацією, впливом на продуктивність, масштабованістю та сценаріями відновлення. Наявність певного механізму захищених копій сама по собі не підтверджує здатність системи підтримувати необхідну кількість знімків у межах однієї системи. Запропонована альтернативна редакція щодо підтримки не менше 100 000 snapshots / point-in-time копій також фактично знижує встановлений Замовником показник у десять разів. У вимозі Учасника не наведено технічного обґрунтування, чому саме такий зменшений показник забезпечує для Замовника той самий запас масштабування, розвиток інфраструктури та рівень захисту даних. Також формулювання «без суттєвого впливу на продуктивність» є менш визначеним порівняно з вимогою тендерної документації щодо створення знімків, що не впливає на продуктивність системи збереження даних. Оціночне поняття «суттєвий вплив» може допускати різне тлумачення та не забезпечує для Замовника того самого рівня визначеності. З наданих Учасником аргументів Замовник не вбачає, що показник 1?10^6 знімків є унікальним для одного виробника або об’єктивно унеможливлює участь інших учасників. Водночас запропонована Учасником редакція не підтверджує збереження того самого рівня масштабування, визначеності технічної специфікації та запасу розвитку системи збереження даних.

Дата оприлюднення відповіді: 24.05.2026 16:57

Звернення за лотом: №1, Серверне, мережеве обладнання та матеріали до нього

Тема: Вимога щодо application-consistent snapshots для MS SQL, Oracle, Exchange, Vmware

Зміст: Шановний Замовнику! У технічних вимогах зазначено: «Можливість створення консистентних snapshots типу application-consistent snapshots окремого ПЗ MS SQL, Oracle DB, MS Exchange, VMware із засобами реплікації на віддалену СЗД того ж вендора та відновлення з реплікованих знімків.» Звертаємо увагу, що механізми application-consistent snapshots у сучасних enterprise СЗД можуть реалізовуватись різними способами: засобами самої СЗД; через VMware integration; Microsoft VSS; Oracle integration; API; agents; orchestration tools; backup software; або інші офіційно підтримувані механізми виробника. При цьому забезпечуються: консистентність даних; коректне відновлення прикладного ПЗ; point-in-time recovery; orchestration recovery workflows; disaster recovery. За нашою технічною оцінкою, вимога щодо реплікації саме на СЗД того ж вендора може суттєво обмежувати конкуренцію та виключати рішення, які підтримують: мультивендорну реплікацію; інтеграцію з backup software; replication gateways; cloud DR; VMware SRM; Veeam; Commvault; Rubrik; або інші офіційно підтримувані механізми резервування та відновлення. Відповідно до вимог Закону України «Про публічні закупівлі», технічна специфікація не повинна містити дискримінаційних вимог або вимог, що обмежують конкуренцію. Також під час дії воєнного стану закупівлі здійснюються з урахуванням Особливостей, затверджених постановою КМУ №1178 від 12.10.2022. Для Замовника функціонально важливими є: можливість створення application-consistent snapshots; консистентне відновлення прикладного ПЗ; реплікація даних; disaster recovery; безпечне резервування, а не конкретна реалізація механізму реплікації або прив’язка до СЗД того ж виробника. З метою забезпечення добросовісної конкуренції, недискримінації учасників та можливості запропонувати еквівалентні рішення різних виробників, просимо викласти вимогу у наступній редакції: «СЗД повинна підтримувати створення консистентних snapshots / point-in-time копій для віртуалізованих середовищ та прикладного ПЗ, зокрема VMware та Microsoft VSS-сумісних застосунків, засобами СЗД, інтегрованого ПЗ виробника, офіційно підтримуваних API, агентів або інших штатних механізмів виробника. СЗД повинна підтримувати реплікацію snapshots / volume copies на віддалену систему, резервну систему або хмарне середовище засобами виробника.»

Дата оприлюднення звернення: 21.05.2026 21:43

Добрий день. Шановний Учаснику у Додатку 2 до тендерної документації передбачено можливість створення консистентних знімків типу application-consistent snapshots для MS SQL, Oracle DB, MS Exchange, VMware із засобами реплікації на віддалену систему збереження даних того ж виробника та відновлення з реплікованих знімків. Ця вимога встановлена не лише для факту створення знімку, а для забезпечення повного сценарію захисту даних: створення консистентного знімку прикладного програмного забезпечення, його реплікації на віддалену систему та подальшого відновлення саме з реплікованого знімка. Окремо Замовник звертає увагу, що запропонована Учасником редакція істотно змінює зміст початкової вимоги Замовника. У чинній редакції тендерної документації йдеться не лише про створення копії даних, а про повний сценарій: створення application-consistent snapshots для визначеного прикладного програмного забезпечення — MS SQL, Oracle DB, MS Exchange, VMware, реплікацію на віддалену систему збереження даних того ж виробника та відновлення саме з реплікованих знімків. Натомість запропонована Учасником редакція замінює цю вимогу на ширше та менш визначене формулювання щодо «snapshots / point-in-time копій» для віртуалізованих середовищ та VMware / Microsoft VSS-сумісних застосунків. Таке формулювання не є рівнозначним початковій вимозі Замовника, оскільки не містить прямої вимоги щодо Oracle DB, MS Exchange та відновлення саме з реплікованих application-consistent snapshots. Крім того, поняття point-in-time copy або volume copy само по собі не гарантує узгодженість (консистентність) прикладного програмного забезпечення. Такі копії можуть забезпечувати фіксацію стану даних на певний момент часу, але не обов’язково гарантують коректну підготовку прикладної системи до створення знімку та подальше відновлення їх у консистентному стані. Також запропонована Учасником редакція передбачає можливість реплікації на «віддалену систему, резервну систему або хмарне середовище». Таке формулювання є значно ширшим за вимогу тендерної документації та допускає використання проміжних рішень, зокрема програмного забезпечення резервного копіювання, шлюзів реплікації, хмарних сервісів або інших компонентів. Для Замовника це не є рівнозначним реплікації на віддалену систему збереження даних того ж виробника, оскільки може призводити до розподілу відповідальності між різними виробниками, додаткових залежностей та ускладнення відновлення у разі аварійної ситуації. Вимога не є унікальною для одного виробника. На ринку наявні системи збереження даних різних виробників, які у відповідних конфігураціях підтримують консистентні знімки, реплікацію та відновлення даних у межах офіційно підтримуваної архітектури, зокрема NetApp AFF/ASA, Dell PowerStore/PowerMax, HPE Alletra / Primera та інші рішення відповідного класу. Отже, запропонована Учасником редакція не лише розширює можливі способи реалізації, а фактично знижує визначеність вимоги: прибирає пряму прив’язку до відновлення з реплікованих знімків, допускає менш визначені point-in-time / volume copies та замінює інтегрований механізм системи збереження даних на можливе поєднання різних зовнішніх або проміжних засобів.

Дата оприлюднення відповіді: 24.05.2026 16:59

Звернення за тендером: Серверне, мережеве обладнання та матеріали до нього

Тема: щодо NBD onsite саме від виробника

Зміст: Шановний Замовнику! У технічних вимогах зазначено: «Наявність авторизованого вендором сервісного центру в Україні»; «Термін гарантії на товар від виробника устаткування, що постачається: не менше 36 місяців 9x5 NBD час реакції з виїздом інженера на місце встановлення обладнання». Звертаємо увагу, що обмеження гарантійної та сервісної підтримки виключно авторизованим сервісним центром виробника на території України може суттєво звужувати коло потенційних учасників та виробників, особливо в умовах дії воєнного стану. На сьогодні значна кількість міжнародних виробників реалізує сервісну підтримку через: офіційних сервісних партнерів; дистриб’юторів; локальних інтеграторів; replacement support; advanced replacement; remote support; регіональні сервісні хаби; або інші офіційно підтримувані виробником механізми. При цьому забезпечуються: гарантійні зобов’язання виробника; підтримка 9x5; NBD replacement / repair; технічна підтримка; заміна обладнання або компонентів; виїзд інженера за необхідності. За нашою технічною оцінкою, вимога щодо наявності саме авторизованого сервісного центру виробника в Україні може відповідати обмеженому колу виробників та створювати дискримінаційні умови участі. Відповідно до вимог Закону України «Про публічні закупівлі», технічна специфікація не повинна містити вимог, що обмежують конкуренцію або призводять до дискримінації учасників. Також під час дії воєнного стану закупівлі здійснюються з урахуванням Особливостей, затверджених постановою КМУ №1178 від 12.10.2022. З метою забезпечення добросовісної конкуренції та можливості участі ширшого кола виробників та учасників, просимо викласти вимогу у наступній редакції: «Гарантійна підтримка комутаторів повинна надаватися протягом не менше 36 місяців з можливістю NBD replacement / repair / support через виробника, офіційне представництво, авторизованого сервісного партнера або офіційного постачальника.»

Дата оприлюднення звернення: 21.05.2026 21:43

Добрий день. Шановний Учаснику у Додатку 2 до тендерної документації для комутаторів передбачено наявність авторизованого виробником сервісного центру в Україні та гарантійну підтримку не менше 36 місяців 9x5 NBD з виїздом інженера на місце встановлення обладнання. Зазначена вимога не означає, що сервісний центр обов’язково має бути власним структурним підрозділом виробника. Йдеться про сервісний канал, офіційно авторизований виробником обладнання та здатний забезпечити гарантійне обслуговування, доступ до запасних частин, технічної підтримки виробника та виїзд інженера на місце встановлення обладнання відповідно до умов тендерної документації. Окремо Замовник звертає увагу, що у вимозі Учасник посилається на різні офіційно підтримувані виробником моделі сервісного обслуговування, однак у запропонованій редакції просить допустити надання підтримки також через «офіційного постачальника». Сам по собі статус офіційного постачальника не є тотожним статусу авторизованого сервісного центру або сервісного партнера, уповноваженого виробником. Такий статус може підтверджувати канал постачання товару, однак не обов’язково підтверджує наявність сервісної компетенції, інженерних ресурсів, доступу до гарантійного каналу виробника, запасних частин та можливості забезпечити виїзд інженера у строки, визначені тендерною документацією. Крім того, запропонована Учасником редакція містить формулювання «з можливістю NBD replacement / repair / support», яке не встановлює чіткого та безумовного обов’язку забезпечити гарантійну підтримку саме у форматі 9x5 NBD з виїздом інженера на місце встановлення обладнання. Таке формулювання допускає різні варіанти підтримки — заміну, ремонт або консультаційну підтримку — без визначення обов’язкового механізму реагування, виїзного сервісу та відповідальності за фактичне відновлення працездатності обладнання. Отже, запропонована Учасником редакція не лише розширює коло можливих сервісних моделей, а фактично замінює визначене тендерною документацією зобов’язання щодо гарантійної підтримки та виїзного сервісу на більш загальну і менш визначену можливість отримання одного з варіантів підтримки. Відповідно до пункту 3 частини другої статті 22 та частини першої статті 23 Закону України «Про публічні закупівлі» Замовник має право визначати необхідні технічні, якісні та функціональні характеристики предмета закупівлі. Крім того, відповідно до частини п’ятої статті 23 Закону Замовник має право вимагати підтвердження того, що запропонований товар за своїми характеристиками відповідає вимогам тендерної документації. З наданих Учасником аргументів Замовником не вбачається, що вимога щодо наявності авторизованого виробником сервісного центру в Україні є унікальною для одного виробника або об’єктивно унеможливлює участь інших Учасників. Також не наведено достатнього підтвердження, що запропонована Учасником редакція забезпечить для Замовника той самий рівень гарантійної підтримки, виїзного сервісу, відповідальності виробника та оперативного відновлення працездатності обладнання.

Дата оприлюднення відповіді: 24.05.2026 17:00

Звернення за тендером: Серверне, мережеве обладнання та матеріали до нього

Тема: Щодо комплектації кабельною інфраструктурою

Зміст: Шановний Замовнику! Дякуємо за надану відповідь у попередньому роз'ясненні. Разом з тим, з огляду на зміст відповідей, окремі питання залишаються неврегульованими, а ряд вимог технічного завдання продовжує мати ознаки дискримінаційного характеру. У зв'язку з цим просимо надати додаткові роз'яснення та внести уточнення. Питання 1. Щодо комплектації кабельною інфраструктурою 25Gb iSCSI портів У попередньому роз'ясненні Замовник зазначив: «Ми згодні, що тип підключення не впливає на його функціональні характеристики, але заміна DAC-кабелю на оптичне з'єднання веде за собою закупівлю не 8 а 16 трансіверів... що, враховуючи невелику відстань між СЗД та комутаторами, необґрунтовано подорожчає... рішення (близько $3 136 за 8 DAC-кабелів та $23 160 за 16 трансіверів та 8 оптичних кабелів)... Технічну вимогу залишаємо без змін». Звертаємо увагу Замовника на наступне: 1.1. У нашому попередньому запиті ми не пропонували замінити DAC-кабелі на оптичне з'єднання. Запропоноване формулювання передбачало альтернативну (диз'юнктивну) комплектацію — «8 шт. DAC-кабелів АБО 8 шт. трансиверів SFP28 з оптичними кабелями». Тобто учасник міг би запропонувати будь-який з двох варіантів на власний розсуд, виходячи з архітектури свого рішення та вартості постачання. Це формулювання прямо передбачає можливість постачання саме DAC-кабелів — як того бажає Замовник — і одночасно відкриває можливість для інших технічно еквівалентних варіантів. Збереження вимоги у чинній редакції не має жодного логічного обґрунтування з боку економії, оскільки запропонована редакція не виключає DAC-варіант. 1.2. Аргумент Замовника щодо економічної ефективності DAC-кабелів містить методологічну помилку: розглядається вартість лише кабельної інфраструктури як ізольованого компонента, без урахування вартості СЗД та інтерфейсних карток, які підтримують відповідні типи підключення. Загальна вартість рішення (TCO) визначається не вартістю кабелів, а сукупною вартістю СЗД, інтерфейсних карток, трансиверів та кабелів у комплексі. 1.3. На практиці, рішення, що підтримує DAC-кабелі 25Gb SFP28-SFP28 Cu, може бути суттєво дорожчим у частині самої СЗД та інтерфейсних карток, ніж рішення на базі оптичних трансиверів — у залежності від моделі та виробника. Економія $20 000 на кабельній інфраструктурі може супроводжуватися переплатою у сотні тисяч доларів США на основному обладнанні через обмежений вибір сумісних СЗД. Таким чином, фокусування на вартості допоміжних кабельних компонентів без аналізу повного TCO не може слугувати обґрунтуванням збереження дискримінаційної вимоги. 1.4. Окремо зауважимо, що сам Замовник у попередньому роз'ясненні визнав: «тип підключення не впливає на його функціональні характеристики». Це є прямим підтвердженням, що вимога не має технічного обґрунтування і має лише комплектаційний характер. Відповідно до частини 4 статті 22 Закону України «Про публічні закупівлі», вимоги тендерної документації, що не мають функціонального обґрунтування і обмежують конкуренцію, є неприпустимими. Просимо повторно розглянути та внести наступну зміну до тендерної документації: «Наявність мінімум 8 портів 25Gb iSCSI у комплекті з кабельною інфраструктурою для підключення: — 8 шт. DAC-кабелів 25Gb SFP28-SFP28 Cu, 2м (сумісних з запропонованими комутаторами); — АБО 8 шт. трансиверів SFP28 з оптичними кабелями LC-LC OM4 Duplex 2м та 8шт трансиверів для зворотного боку підключення до комутаторів); — АБО еквівалентна за функціональністю комплектація на вибір учасника». Така редакція повністю зберігає можливість DAC-варіанту як бажаного для Замовника, а додаткові опції є диспозитивними для учасника.

Дата оприлюднення звернення: 21.05.2026 22:02

Добрий день. Шановний Учаснику у Додатку 2 до тендерної документації передбачено наявність мінімум 8 портів 25Gb iSCSI у комплекті з DAC-кабелями 25Gb SFP28-SFP28 Cu довжиною 2 м. Зазначена вимога встановлена не як довільне обмеження способу передавання даних, а як вимога до визначеної комплектації системи збереження даних для конкретної проєктної схеми підключення до комутаторів, з урахуванням короткої відстані між обладнанням, уніфікації кабельної інфраструктури, зменшення кількості окремих компонентів підключення та прогнозованості експлуатації. Замовник бере до уваги пояснення Учасника, що запропонована ним редакція не виключає постачання DAC-кабелів. Водночас така редакція фактично передає вибір кабельної інфраструктури на розсуд учасника та дозволяє постачання будь-якого з декількох варіантів підключення, у тому числі оптичного або іншого «еквівалентного» варіанту. Однак Замовник має об’єктивну потребу отримати не будь-який технічно можливий спосіб підключення, а саме визначену комплектацію, сумісну з проєктним розміщенням обладнання, наявними вимогами до комутаторів та очікуваною схемою монтажу. Посилання Учасника на необхідність оцінки повної вартості рішення не підтверджене жодним конкретним розрахунком. У зверненні не наведено конкретних моделей систем збереження даних, інтерфейсних карток, трансиверів, порівняльної таблиці вартості або технічного підтвердження того, що вимога щодо DAC-кабелів призводить до суттєвого здорожчання всього рішення чи унеможливлює участь інших виробників. Твердження про можливу переплату «у сотні тисяч доларів США» має припущений характер і не може вважатися належним доказом дискримінаційності вимоги. Також сам факт того, що різні типи підключення можуть забезпечувати передачу даних на однаковій швидкості, не означає їх повної рівнозначності для цілей цієї закупівлі. Для Замовника значення має не лише функціональна можливість передати трафік, а й кількість компонентів у лінії підключення, сумісність із запропонованими комутаторами, простота монтажу, зменшення потенційних точок відмови, єдина відповідальність за комплект поставки та передбачуваність подальшої експлуатації. Відповідно до пункту 3 частини другої статті 22 та частини першої статті 23 Закону України «Про публічні закупівлі» Замовник має право визначати необхідні технічні, якісні та кількісні характеристики предмета закупівлі, у тому числі вимоги до комплектації товару. З наданих Учасником аргументів Замовником не вбачається, що встановлена вимога є унікальною для одного виробника або об’єктивно унеможливлює участь інших учасників. З огляду на викладене, запропонована Учасником редакція не приймається, а вимога щодо наявності мінімум 8 портів 25Gb iSCSI у комплекті з DAC-кабелями 25Gb SFP28-SFP28 Cu довжиною 2 м залишається без змін.

Дата оприлюднення відповіді: 24.05.2026 17:02

Звернення за тендером: Серверне, мережеве обладнання та матеріали до нього

Тема: Звернення щодо усунення дискримінаційних вимог тендерної документації

Зміст: Шановний Замовнику! Після аналізу тендерної документації до закупівлі «Серверне, мережеве обладнання та матеріали до нього» вважаємо, що технічна специфікація містить низку надмірно деталізованих вимог, які у сукупності фактично орієнтують закупівлю на обладнання та програмну екосистему одного виробника. Зазначені вимоги описують не функціональний результат, необхідний Замовнику, а конкретну архітектуру, внутрішні механізми реалізації, термінологію та модель керування, характерні для обмеженого кола виробників. У результаті формальна можливість запропонувати «еквівалент» фактично нівелюється, оскільки еквівалентні рішення інших виробників не можуть відповідати всій сукупності таких вимог без зміни власної архітектури. Наголошуємо, що проблема полягає не в одному окремому пункті, а саме в сукупному обмежувальному ефекті технічної документації. Окремі конкретні питання щодо відповідних вимог були / можуть бути подані додатково, однак це звернення стосується загальної побудови технічної специфікації, яка звужує конкуренцію. Відповідно до Закону України «Про публічні закупівлі», технічна специфікація не повинна містити посилання на конкретну торговельну марку, фірму, патент, конструкцію, тип предмета закупівлі, джерело походження або виробника, а у разі необхідності такого посилання воно має бути обґрунтованим та містити вираз «або еквівалент». Водночас наявність слів «або еквівалент» не усуває дискримінаційний характер вимог, якщо вся сукупність характеристик фактично відповідає одному виробнику та не дозволяє іншим виробникам підтвердити відповідність через інші, але рівноцінні технічні рішення. У зв’язку з цим просимо Замовника: Надати технічне обґрунтування, чому саме такі архітектурні, конструктивні та програмні вимоги є критично необхідними для досягнення мети закупівлі. Пояснити, яким чином еквівалентні рішення інших виробників можуть відповідати вимогам, якщо їх архітектура, механізми захисту даних, snapshots, replication, high availability, interconnect або централізоване керування реалізовані іншим способом. У разі якщо Замовник вважає, що вимогам відповідає більше одного виробника, просимо навести приклади щонайменше двох незалежних виробників, рішення яких у сукупності відповідають усім встановленим вимогам без зміни ключових параметрів технічної специфікації. Виключити або переформулювати вимоги, які описують конкретну архітектуру, внутрішні механізми, назви технологій або закриту програмну екосистему окремого виробника. Викласти технічні вимоги у функціонально нейтральній редакції — через продуктивність, корисну ємність, відмовостійкість, доступність, сумісність, підтримувані протоколи, захист даних, можливість моніторингу, масштабування та гарантійну підтримку. Просимо не обмежуватися загальним посиланням на потреби Замовника або наявність формулювання «або еквівалент», а надати відповідь по суті: чому сукупність встановлених вимог не обмежує конкуренцію та не створює перевагу одному виробнику. У разі відсутності належного технічного обґрунтування просимо внести зміни до тендерної документації та усунути дискримінаційні вимоги. Вважаємо, що без внесення таких змін дана технічна специфікація створює ризик порушення принципів добросовісної конкуренції, недискримінації учасників, рівного ставлення до них та прозорості процедури закупівлі.

Дата оприлюднення звернення: 21.05.2026 22:10

Доброго дня. Шановний Учаснику Замовник розглянув звернення та повідомляє наступне. Відповідно до пункту 3 частини другої статті 22 Закону України «Про публічні закупівлі» тендерна документація повинна містити інформацію про необхідні технічні, якісні та кількісні характеристики предмета закупівлі, у тому числі технічну специфікацію. Відповідно до частини першої статті 23 Закону України «Про публічні закупівлі» технічна специфікація повинна містити опис усіх необхідних характеристик товарів, у тому числі їх технічні, функціональні та якісні характеристики. Відповідно до частини третьої статті 23 Закону України «Про публічні закупівлі» технічні специфікації можуть бути у формі експлуатаційних або функціональних вимог, якщо такі вимоги є достатньо точними для однозначного розуміння предмета закупівлі замовником і учасниками. Предметом закупівлі є комплекс серверного, мережевого обладнання, системи збереження даних, оптичних модулів та з’єднувальних шнурів, який має бути сумісним з існуючим у Замовника обладнанням. Встановлені вимоги спрямовані на забезпечення продуктивності, відмовостійкості, сумісності, масштабованості, резервування, централізованого управління, гарантійної підтримки та захисту даних. Такі характеристики прямо пов’язані з метою закупівлі та є об’єктивно необхідними для належної експлуатації обладнання. Замовник не погоджується з твердженням про дискримінаційність вимог. Вимога містить загальні твердження про нібито «сукупний обмежувальний ефект», однак не містить конкретного технічного аналізу, не визначає які саме положення тендерної документації унеможливлюють участь Учасника, не містить порівняння з обладнанням різних виробників та не підтверджує документально, що встановленим вимогам може відповідати лише один виробник. Технічна специфікація не встановлює обов’язку постачання обладнання конкретної торговельної марки чи конкретної моделі. Вимоги сформовані через мінімально необхідні характеристики: «не менше», «не гірше», підтримку визначених протоколів, рівень продуктивності, резервування, масштабування, сервісної підтримки та функціональних можливостей. Щодо твердження Учасника про нібито орієнтацію вимог на одного виробника зазначаємо, що на ринку наявні рішення різних незалежних виробників, які за належної конфігурації можуть відповідати встановленому класу обладнання та функціональним потребам Замовника, зокрема: • сервери віртуалізації: HPE ProLiant Compute DL360 Gen12, Dell PowerEdge R670, Lenovo ThinkSystem SR630 V4, Fujitsu PRIMERGY RX2530 M8; • комутатори для центрів обробки даних: HPE Aruba Networking CX 8325-48Y8C, Juniper EX4650-48Y-AFI, Arista DCS-7050SX3-24YC4C, H3C S6530X-24Y8C; • системи збереження даних корпоративного класу з підтримкою NVMe та SAN-протоколів: NetApp ASA/AFF C-Series, HPE Alletra Storage MP B10000, Dell PowerStore 9200T. Наведені приклади не є вичерпним переліком можливих рішень і не обмежують учасників у праві запропонувати інше обладнання, якщо воно відповідає встановленим технічним, якісним та функціональним характеристикам. Остаточна відповідність конкретної моделі та конкретної конфігурації вимогам тендерної документації підтверджується учасником у складі тендерної пропозиції. Вимога щодо надання авторизаційного листа встановлена з метою підтвердження офіційності каналу постачання, права постачання обладнання та можливості забезпечення гарантійної і сервісної підтримки виробника. Тендерна документація також передбачає, що обладнання не повинно мати статус припинення виробництва та/або припинення сервісної підтримки, що прямо пов’язано з забезпеченням належної експлуатації закупленого обладнання протягом гарантійного періоду. З наданих Учасником аргументів Замовником не вбачається, що встановлені вимоги є унікальними для одного виробника та не підтверджується неможливість участі інших виробників. З огляду на викладене, підстави для внесення змін до тендерної документації відсутні.

Дата оприлюднення відповіді: 24.05.2026 17:03