Внимание! Соединение с приложением прервано. Дождитесь повторного подключения.
Обсуждение документации - Просмотр сообщения № 1069945
Тема сообщения
ПИСЬМА, 5 ПРОТОКОЛОВ, КВАЛИФИКАЦИОННЫЕ ТРЕБОВАНИЯ, ИЗМЕНЕНИЕ ТС ПОСЛЕ ДОГОВОРА, ПРИЕМКА И 45 ДНЕЙ
Тип сообщения
Замечание к АД
Поставщик
АРУЖАН
Представитель поставщика
КУЛАКОВ БЕЙБИТ МАДАТАЕВИЧ
Дата и время отправки сообщения
2026-10-08 17:05:44
Текст сообщения
1. Техническая спецификация требует комплексной переработки, поскольку в одном предмете закупки стоимостью 26 270 000 тенге объединено большое количество разнородных серийных товаров и программно-аппаратных решений: 29 моноблоков, автоматизированный спортивный комплекс «Волейбольная пушка», МФУ А3, образовательное программное обеспечение корпоративного уровня, измерительный комплекс из 15 типов беспроводных датчиков и система электробезопасности/умной автоматизации.
2. При этом документ одновременно устанавливает характеристики товара, внутреннюю архитектуру программного обеспечения, квалификационные требования к участнику, обязательные коммерческие документы третьих лиц, требования к сервисным организациям, письменные гарантии участника и даже предварительное согласие на последующее изменение отдельных позиций технической спецификации.
3. Такой подход создает существенный риск неодинакового понимания объема закупки.
4. Наиболее серьезное замечание касается авторизационных документов.
5. По аппаратно-программному комплексу потенциальный поставщик обязан представить авторизационное письмо производителя о праве поставки.
6. Письмо должно содержать QR-код либо специальную ссылку для проверки.
7. Дополнительно участник должен представить документы, подтверждающие право реализации/распространения продукта.
8. ТС прямо упоминает авторское право на исходный код программного обеспечения.
9. Для товара иностранного происхождения официальный представитель либо дистрибьютор в РК дополнительно обязан подтвердить право представлять иностранную компанию.
10. Замена данных документов гарантийными письмами участника прямо запрещается.
11. Сам Заказчик указывает, что документы должны подтверждать «правоспособность конкурсанта» на стадии рассмотрения заявки.
12. Тем самым техническая спецификация напрямую содержит условие, характеризующее юридико-коммерческий статус участника, а не технические свойства товара.
13. Производитель, разработчик и дистрибьютор являются независимыми третьими лицами.
14. Они не обязаны выдавать письмо всем потенциальным участникам.
15. Правообладатель может иметь эксклюзивного дистрибьютора.
16. Может ограничивать тендерные письма одному партнеру.
17. Может вообще не иметь официального представителя в РК.
18. В результате технически соответствующий оригинальный продукт может быть недоступен участнику только из-за закрытой партнерской политики.
19. Просим исключить авторизационные письма как обязательное условие заявки.
20. Законность происхождения должна подтверждаться альтернативно: серийными номерами, инвойсами, лицензионными договорами, сертификатами, товаросопроводительными документами, официальной гарантией либо проверкой при поставке.
21. Еще более ограничивающим является пакет из пяти обязательных протоколов на предлагаемое программное обеспечение.
22. Протокол обследования сетевой инфраструктуры.
23. Протокол обследования процессов информационной безопасности.
24. Протокол нагрузочного испытания.
25. Протокол анализа исходного кода SAST.
26. Протокол испытаний функций информационной безопасности на соответствие СТ РК ISO/IEC 15408-2-2017.
27. Все документы должны быть выданы независимой лабораторией, аккредитованной в системе аккредитации Республики Казахстан.
28. Непредоставление хотя бы одного протокола прямо объявляется несоответствием.
29. Такая совокупность с высокой вероятностью допускает только ПО, которое уже заранее прошло конкретный комплекс испытаний в конкретной юрисдикции.
30. Новый конкурентный продукт не способен получить пять сложных лабораторных протоколов за короткий период предварительного обсуждения и подачи заявок.
31. Особенно SAST-анализ требует доступа к исходному коду разработчика.
32. Обычный реселлер либо интегратор не имеет такого доступа.
33. Следовательно, фактическая возможность участия зависит от заранее существовавшей воли правообладателя провести именно такие испытания.
34. Просим назвать минимум три независимых программных продукта разных разработчиков, у которых на дату объявления закупки существуют все пять действующих протоколов NCA РК.
35. Если минимум три решения отсутствуют, просим убрать совокупность обязательных протоколов и допустить иные эквивалентные доказательства информационной безопасности.
36. Внутренняя архитектура ПО дополнительно привязана к не менее чем 18 логическим модулям, микросервисам/SOA, reverse proxy и масштабированию до 1000 пользователей.
37. При этом серверные минимальные требования далее рассчитываются на 100 пользователей.
38. Данное несоответствие необходимо устранить.
39. Архитектура программного продукта является сферой ответственности разработчика.
40. Требовать необходимо конечный результат: функциональность, доступность, безопасность, производительность и резервное восстановление.
41. Не менее модельно-специфичен комплекс 15 датчиков.
42. Он обязан использовать локальную Wi-Fi сеть самого приемника.
43. Только WebSocket RFC 6455.
44. Только JSON.
45. Датчики с ID минимум 8 символов.
46. АКБ минимум 1000 мА·ч.
47. Интерфейс строго Dark Theme.
48. Пятнадцать карточек.
49. Статус «НЕАКТИВЕН» строго красный в форме таблетки.
50. Подобные признаки не являются требованиями к качеству измерений.
51. Они описывают конкретную реализацию интерфейса.
52. Просим убрать техническую привязку и оставить диапазоны, погрешность, автономность, задержку и отображаемые данные.
53. Отдельный блок ограничений содержится в системе электробезопасности.
54. Комплект должен быть единой экосистемой одного программного обеспечения.
55. Хаб должен конструктивно совмещать камеру, ночную ИК-подсветку, микрофон, динамик, сигнализацию и управление минимум 64 устройствами.
56. При этом в поставке всего одна розетка и один выключатель.
57. Требование 64 устройств требует экономического и функционального обоснования.
58. Повторно установлено авторизационное письмо производителя с QR-кодом и запрет гарантийного письма.
59. То есть сразу несколько компонентов лота фактически требуют вступления участника в определенные партнерские цепочки.
60. Система дополнительно требует авторизованного или собственного сервисного центра либо договора с сервисной организацией.
61. Неясно, в какой момент необходимо подтвердить данный сервисный статус.
62. Если в заявке — это очередное квалификационное условие внутри ТС.
63. Следующая серьезная проблема содержится в заключительной части документа.
64. Участник обязан предоставить отдельный документ, подтверждающий готовность получить «все необходимые согласования и разрешения для выполнения работ, если таковые потребуются».
65. При этом перечень разрешений отсутствует.
66. Не указаны органы выдачи.
67. Не указаны сроки.
68. Не указана стоимость.
69. Невозможно подписать экономически обоснованное согласие на неопределенный перечень будущих обязательств.
70. Участник также должен представить письменную гарантию соблюдения внутреннего распорядка, невмешательства в учебный процесс и выполнения работ по согласованному графику.
71. Эти условия являются условиями исполнения договора и могут быть установлены непосредственно в договоре.
72. Нет необходимости превращать каждое договорное обязательство в отдельный документ заявки.
73. Далее участник обязан обладать «достаточными материальными и трудовыми ресурсами (квалифицированным персоналом)».
74. Не определено, что понимается под достаточностью.
75. Не указано количество работников.
76. Не указана квалификация.
77. Не указаны дипломы либо допуски.
78. Не указано необходимое оборудование.
79. В результате соответствие зависит от субъективной оценки комиссии.
80. Если такие ресурсы действительно необходимы, они должны быть сформулированы четко в предусмотренном для квалификационных требований разделе, а не скрыты внутри характеристики товара.
81. Еще более проблемное требование — отдельное письменное согласие участника на возможное изменение отдельных позиций технической спецификации в процессе выполнения работ.
82. Изменения допускаются по согласованию с Заказчиком при сохранении общего объема финансирования.
83. На момент подачи предложения участник обязан определить себестоимость исходя из опубликованного состава.
84. Если после заключения договора Заказчик вправе менять отдельные позиции, поставщик заранее не знает фактический ассортимент.
85. Замена может изменить производителя.
86. Закупочную цену.
87. логистику.
88. гарантию.
89. сроки.
90. лицензионную модель.
91. совместимость.
92. Понятие «сохранение общего объема финансирования» не устраняет эти риски.
93. Более дорогая замена при той же общей цене фактически перекладывает расходы на победителя.
94. Более дешевая замена способна изменить экономический баланс закупки.
95. Просим полностью исключить предварительное согласие на неопределенные будущие изменения.
96. Если допускается эквивалентная замена, критерии и случаи должны быть заранее исчерпывающе установлены в документации.
97. Отдельного внимания требует срок 45 календарных дней.
98. За этот срок необходимо поставить 29 моноблоков.
99. Специализированную волейбольную пушку.
100. Цветное МФУ А3.
101. программную платформу.
102. программно-аппаратный набор из 15 беспроводных датчиков.
103. систему электробезопасности.
104. обеспечить приложения, лицензии, документацию и необходимые настройки.
105. При этом аванс равен нулю.
106. Специализированное оборудование может не находиться на складе в Казахстане.
107. 45 дней способны создать преимущество участнику, который заранее располагает именно той аппаратурой, под которую составлена ТС.
108. Просим увеличить срок до 60 календарных дней.
109. Еще один системный вопрос — гарантия.
110. Общая форма устанавливает 12 месяцев.
111. Волейбольная пушка имеет отдельные гарантийные требования.
112. ПО имеет SLA минимум 12 месяцев.
113. датчики — минимум 12 месяцев.
114. система электробезопасности — минимум 12 месяцев.
115. МФУ — минимум 12 месяцев.
116. Необходимо определить единый момент начала гарантии — итоговый акт по всему комплекту или отдельные акты по каждой подсистеме.
117. Следующая проблема — отсутствие единой ведомости комплектности.
118. Предмет закупки обозначен одной единицей «комплект», но внутри 146-страничного документа содержится большое число независимых товаров.
119. Участникам необходимо самостоятельно извлекать количество каждой позиции из сплошного текста.
120. Это увеличивает риск пропуска компонента и неодинакового формирования цены.
121. Просим опубликовать сводную таблицу: позиция, количество, гарантия, необходимость ПО/лицензии, монтаж, настройка, обучение, требования к авторизации и приемочному испытанию.
122. Также необходимо установить единый приемочный сценарий.
123. Для 29 моноблоков — проверка основных характеристик и серийных номеров.
124. Для пушки — скорость, точность, автономность и режимы.
125. Для МФУ — A3, скорость, сканирование и сеть.
126. Для ПО — пользователи, 3D, игровой сервер, безопасность.
127. Для 15 датчиков — диапазон, погрешность и задержка.
128. Для электробезопасности — управление, защита и локальная работа.
129. Сейчас многие показатели либо требуют специальных приборов, либо зависят от сети, либо вообще не имеют определенной методики проверки.
130. Без приемочного протокола возникает риск субъективного отказа от товара.
131. Просим в целом переработать ТС по принципу функциональной нейтральности.
132. Требования должны определять образовательный и эксплуатационный результат, а не коммерческие отношения поставщика с правообладателями, внутреннюю структуру исходного кода, конкретный UI, точный тип механической передачи либо заранее сформированную smart-home экосистему.
133. Просим также подтвердить наличие минимум трех независимых вариантов поставки всего комплекта, при которых каждый из ключевых компонентов может быть предложен от альтернативного производителя без необходимости получать документы от одного заранее определенного правообладателя.
134. В противном случае совокупность требований имеет признаки существенного ограничения конкурентного доступа и должна быть скорректирована до окончания предварительного обсуждения.
2. При этом документ одновременно устанавливает характеристики товара, внутреннюю архитектуру программного обеспечения, квалификационные требования к участнику, обязательные коммерческие документы третьих лиц, требования к сервисным организациям, письменные гарантии участника и даже предварительное согласие на последующее изменение отдельных позиций технической спецификации.
3. Такой подход создает существенный риск неодинакового понимания объема закупки.
4. Наиболее серьезное замечание касается авторизационных документов.
5. По аппаратно-программному комплексу потенциальный поставщик обязан представить авторизационное письмо производителя о праве поставки.
6. Письмо должно содержать QR-код либо специальную ссылку для проверки.
7. Дополнительно участник должен представить документы, подтверждающие право реализации/распространения продукта.
8. ТС прямо упоминает авторское право на исходный код программного обеспечения.
9. Для товара иностранного происхождения официальный представитель либо дистрибьютор в РК дополнительно обязан подтвердить право представлять иностранную компанию.
10. Замена данных документов гарантийными письмами участника прямо запрещается.
11. Сам Заказчик указывает, что документы должны подтверждать «правоспособность конкурсанта» на стадии рассмотрения заявки.
12. Тем самым техническая спецификация напрямую содержит условие, характеризующее юридико-коммерческий статус участника, а не технические свойства товара.
13. Производитель, разработчик и дистрибьютор являются независимыми третьими лицами.
14. Они не обязаны выдавать письмо всем потенциальным участникам.
15. Правообладатель может иметь эксклюзивного дистрибьютора.
16. Может ограничивать тендерные письма одному партнеру.
17. Может вообще не иметь официального представителя в РК.
18. В результате технически соответствующий оригинальный продукт может быть недоступен участнику только из-за закрытой партнерской политики.
19. Просим исключить авторизационные письма как обязательное условие заявки.
20. Законность происхождения должна подтверждаться альтернативно: серийными номерами, инвойсами, лицензионными договорами, сертификатами, товаросопроводительными документами, официальной гарантией либо проверкой при поставке.
21. Еще более ограничивающим является пакет из пяти обязательных протоколов на предлагаемое программное обеспечение.
22. Протокол обследования сетевой инфраструктуры.
23. Протокол обследования процессов информационной безопасности.
24. Протокол нагрузочного испытания.
25. Протокол анализа исходного кода SAST.
26. Протокол испытаний функций информационной безопасности на соответствие СТ РК ISO/IEC 15408-2-2017.
27. Все документы должны быть выданы независимой лабораторией, аккредитованной в системе аккредитации Республики Казахстан.
28. Непредоставление хотя бы одного протокола прямо объявляется несоответствием.
29. Такая совокупность с высокой вероятностью допускает только ПО, которое уже заранее прошло конкретный комплекс испытаний в конкретной юрисдикции.
30. Новый конкурентный продукт не способен получить пять сложных лабораторных протоколов за короткий период предварительного обсуждения и подачи заявок.
31. Особенно SAST-анализ требует доступа к исходному коду разработчика.
32. Обычный реселлер либо интегратор не имеет такого доступа.
33. Следовательно, фактическая возможность участия зависит от заранее существовавшей воли правообладателя провести именно такие испытания.
34. Просим назвать минимум три независимых программных продукта разных разработчиков, у которых на дату объявления закупки существуют все пять действующих протоколов NCA РК.
35. Если минимум три решения отсутствуют, просим убрать совокупность обязательных протоколов и допустить иные эквивалентные доказательства информационной безопасности.
36. Внутренняя архитектура ПО дополнительно привязана к не менее чем 18 логическим модулям, микросервисам/SOA, reverse proxy и масштабированию до 1000 пользователей.
37. При этом серверные минимальные требования далее рассчитываются на 100 пользователей.
38. Данное несоответствие необходимо устранить.
39. Архитектура программного продукта является сферой ответственности разработчика.
40. Требовать необходимо конечный результат: функциональность, доступность, безопасность, производительность и резервное восстановление.
41. Не менее модельно-специфичен комплекс 15 датчиков.
42. Он обязан использовать локальную Wi-Fi сеть самого приемника.
43. Только WebSocket RFC 6455.
44. Только JSON.
45. Датчики с ID минимум 8 символов.
46. АКБ минимум 1000 мА·ч.
47. Интерфейс строго Dark Theme.
48. Пятнадцать карточек.
49. Статус «НЕАКТИВЕН» строго красный в форме таблетки.
50. Подобные признаки не являются требованиями к качеству измерений.
51. Они описывают конкретную реализацию интерфейса.
52. Просим убрать техническую привязку и оставить диапазоны, погрешность, автономность, задержку и отображаемые данные.
53. Отдельный блок ограничений содержится в системе электробезопасности.
54. Комплект должен быть единой экосистемой одного программного обеспечения.
55. Хаб должен конструктивно совмещать камеру, ночную ИК-подсветку, микрофон, динамик, сигнализацию и управление минимум 64 устройствами.
56. При этом в поставке всего одна розетка и один выключатель.
57. Требование 64 устройств требует экономического и функционального обоснования.
58. Повторно установлено авторизационное письмо производителя с QR-кодом и запрет гарантийного письма.
59. То есть сразу несколько компонентов лота фактически требуют вступления участника в определенные партнерские цепочки.
60. Система дополнительно требует авторизованного или собственного сервисного центра либо договора с сервисной организацией.
61. Неясно, в какой момент необходимо подтвердить данный сервисный статус.
62. Если в заявке — это очередное квалификационное условие внутри ТС.
63. Следующая серьезная проблема содержится в заключительной части документа.
64. Участник обязан предоставить отдельный документ, подтверждающий готовность получить «все необходимые согласования и разрешения для выполнения работ, если таковые потребуются».
65. При этом перечень разрешений отсутствует.
66. Не указаны органы выдачи.
67. Не указаны сроки.
68. Не указана стоимость.
69. Невозможно подписать экономически обоснованное согласие на неопределенный перечень будущих обязательств.
70. Участник также должен представить письменную гарантию соблюдения внутреннего распорядка, невмешательства в учебный процесс и выполнения работ по согласованному графику.
71. Эти условия являются условиями исполнения договора и могут быть установлены непосредственно в договоре.
72. Нет необходимости превращать каждое договорное обязательство в отдельный документ заявки.
73. Далее участник обязан обладать «достаточными материальными и трудовыми ресурсами (квалифицированным персоналом)».
74. Не определено, что понимается под достаточностью.
75. Не указано количество работников.
76. Не указана квалификация.
77. Не указаны дипломы либо допуски.
78. Не указано необходимое оборудование.
79. В результате соответствие зависит от субъективной оценки комиссии.
80. Если такие ресурсы действительно необходимы, они должны быть сформулированы четко в предусмотренном для квалификационных требований разделе, а не скрыты внутри характеристики товара.
81. Еще более проблемное требование — отдельное письменное согласие участника на возможное изменение отдельных позиций технической спецификации в процессе выполнения работ.
82. Изменения допускаются по согласованию с Заказчиком при сохранении общего объема финансирования.
83. На момент подачи предложения участник обязан определить себестоимость исходя из опубликованного состава.
84. Если после заключения договора Заказчик вправе менять отдельные позиции, поставщик заранее не знает фактический ассортимент.
85. Замена может изменить производителя.
86. Закупочную цену.
87. логистику.
88. гарантию.
89. сроки.
90. лицензионную модель.
91. совместимость.
92. Понятие «сохранение общего объема финансирования» не устраняет эти риски.
93. Более дорогая замена при той же общей цене фактически перекладывает расходы на победителя.
94. Более дешевая замена способна изменить экономический баланс закупки.
95. Просим полностью исключить предварительное согласие на неопределенные будущие изменения.
96. Если допускается эквивалентная замена, критерии и случаи должны быть заранее исчерпывающе установлены в документации.
97. Отдельного внимания требует срок 45 календарных дней.
98. За этот срок необходимо поставить 29 моноблоков.
99. Специализированную волейбольную пушку.
100. Цветное МФУ А3.
101. программную платформу.
102. программно-аппаратный набор из 15 беспроводных датчиков.
103. систему электробезопасности.
104. обеспечить приложения, лицензии, документацию и необходимые настройки.
105. При этом аванс равен нулю.
106. Специализированное оборудование может не находиться на складе в Казахстане.
107. 45 дней способны создать преимущество участнику, который заранее располагает именно той аппаратурой, под которую составлена ТС.
108. Просим увеличить срок до 60 календарных дней.
109. Еще один системный вопрос — гарантия.
110. Общая форма устанавливает 12 месяцев.
111. Волейбольная пушка имеет отдельные гарантийные требования.
112. ПО имеет SLA минимум 12 месяцев.
113. датчики — минимум 12 месяцев.
114. система электробезопасности — минимум 12 месяцев.
115. МФУ — минимум 12 месяцев.
116. Необходимо определить единый момент начала гарантии — итоговый акт по всему комплекту или отдельные акты по каждой подсистеме.
117. Следующая проблема — отсутствие единой ведомости комплектности.
118. Предмет закупки обозначен одной единицей «комплект», но внутри 146-страничного документа содержится большое число независимых товаров.
119. Участникам необходимо самостоятельно извлекать количество каждой позиции из сплошного текста.
120. Это увеличивает риск пропуска компонента и неодинакового формирования цены.
121. Просим опубликовать сводную таблицу: позиция, количество, гарантия, необходимость ПО/лицензии, монтаж, настройка, обучение, требования к авторизации и приемочному испытанию.
122. Также необходимо установить единый приемочный сценарий.
123. Для 29 моноблоков — проверка основных характеристик и серийных номеров.
124. Для пушки — скорость, точность, автономность и режимы.
125. Для МФУ — A3, скорость, сканирование и сеть.
126. Для ПО — пользователи, 3D, игровой сервер, безопасность.
127. Для 15 датчиков — диапазон, погрешность и задержка.
128. Для электробезопасности — управление, защита и локальная работа.
129. Сейчас многие показатели либо требуют специальных приборов, либо зависят от сети, либо вообще не имеют определенной методики проверки.
130. Без приемочного протокола возникает риск субъективного отказа от товара.
131. Просим в целом переработать ТС по принципу функциональной нейтральности.
132. Требования должны определять образовательный и эксплуатационный результат, а не коммерческие отношения поставщика с правообладателями, внутреннюю структуру исходного кода, конкретный UI, точный тип механической передачи либо заранее сформированную smart-home экосистему.
133. Просим также подтвердить наличие минимум трех независимых вариантов поставки всего комплекта, при которых каждый из ключевых компонентов может быть предложен от альтернативного производителя без необходимости получать документы от одного заранее определенного правообладателя.
134. В противном случае совокупность требований имеет признаки существенного ограничения конкурентного доступа и должна быть скорректирована до окончания предварительного обсуждения.
