Внимание! Соединение с приложением прервано. Дождитесь повторного подключения.
Обсуждение документации - Просмотр сообщения № 1070036
Тема сообщения
Нарушения в ТС
Тип сообщения
Замечание к АД
Поставщик
Kaz Trade
Представитель поставщика
ТАЛГАРОВ ЕРНАР ЕРКИНҰЛЫ
Дата и время отправки сообщения
2026-10-09 01:11:29
Текст сообщения
1. Техническая спецификация содержит совокупность требований, которые фактически переносят оценку потенциального поставщика с характеристик предлагаемого товара на наличие у него заранее оформленных отношений с производителем, правообладателем, дистрибьютором и конкретными испытательными лабораториями.
2. Согласно ТС участник обязан включить в заявку авторизационное письмо производителя, подтверждающее право поставки предлагаемого продукта. При этом письмо должно содержать QR-код, позволяющий Заказчику провести верификацию через официальный сайт.
3. Просим исключить данное требование либо установить альтернативные способы подтверждения законности происхождения и права поставки продукции.
4. Наличие авторизационного письма не является технической, функциональной, качественной или эксплуатационной характеристикой закупаемого товара.
5. Авторизационное письмо характеризует договорные и коммерческие отношения потенциального поставщика с третьим лицом.
6. Производитель вправе самостоятельно определять дилерскую сеть, число партнеров, территории продаж и порядок выдачи писем.
7. Следовательно, производитель может выдать письмо одному потенциальному поставщику и отказать другому, несмотря на возможность второго участника законно приобрести и поставить оригинальный товар.
8. Государственная закупка при такой конструкции становится зависимой от решения субъекта, не являющегося Заказчиком, Организатором или конкурсной комиссией.
9. Дополнительным ограничением является обязательное наличие в письме QR-кода с возможностью проверки информации на официальном сайте.
10. Не каждый производитель применяет QR-верификацию авторизационных писем.
11. У производителя может использоваться электронная почта, реестр партнеров, электронная подпись, номер документа, личный кабинет либо иная технология проверки.
12. Отсутствие именно QR-кода не означает поддельность документа или контрафактность товара.
13. Просим исключить требование к конкретному техническому способу верификации письма.
14. Дополнительно участник должен представить документы, подтверждающие право реализации/распространения продукта, причем ТС содержит формулировку о «БҚ бастапқы кодына авторлық құқық», то есть об авторских правах на исходный код ПО.
15. Просим разграничить право использования, распространения экземпляров программного обеспечения и авторские права на исходный код.
16. Обычный лицензионный поставщик программного обеспечения не обязан обладать авторским правом на исходный код продукта.
17. Авторское право на исходный код, как правило, принадлежит разработчику или правообладателю.
18. Передача конечному поставщику лицензии или права перепродажи программного продукта не предполагает передачу ему исключительных авторских прав на исходный код.
19. Указанное требование может фактически сделать участие возможным преимущественно для самого разработчика либо узкого круга аффилированных субъектов.
20. Просим исключить требование об авторских правах на исходный код либо четко заменить его требованием о наличии законного права поставки/предоставления лицензии.
21. Для иностранного продукта дополнительно требуется документ официального представителя или дистрибьютора на территории Республики Казахстан, подтверждающий право представлять интересы иностранной компании.
22. Данное территориальное условие также просим исключить.
23. Законная продукция может быть приобретена непосредственно у иностранного производителя.
24. Через международного дистрибьютора.
25. Через регионального поставщика.
26. Через законного импортера.
27. Либо самостоятельно ввезена поставщиком после заключения договора.
28. Отсутствие у производителя локального официального представителя не свидетельствует о контрафактности товара.
29. Территориальная привязка к дилеру/представителю именно в Республике Казахстан искусственно исключает альтернативные законные каналы поставки.
30. ТС прямо запрещает замену запрашиваемых авторизационных документов гарантийным письмом участника, в том числе обязательством представить документы после завершения закупки.
31. Заказчик дополнительно поясняет, что документы должны существовать на стадии рассмотрения заявок и подтверждают «правоспособность конкурсанта».
32. Обращаем внимание, что в примечании самой ТС отдельно установлено: в технической спецификации не допускается устанавливать квалификационные требования к потенциальному поставщику.
33. Использование понятия «правоспособность конкурсанта» применительно к документу, который должен представить именно участник в составе заявки, требует отдельного правового и технического обоснования.
34. Если документ служит доказательством правоспособности лица, а не характеристики товара, необходимо объяснить, почему он включен именно в техническую спецификацию.
35. Помимо авторизационных документов ТС устанавливает исключительно широкий пакет испытательных протоколов на программное обеспечение.
36. Участник обязан представить протокол обследования сетевой инфраструктуры.
37. Протокол исследования процессов обеспечения информационной безопасности.
38. Протокол нагрузочного тестирования.
39. Протокол анализа исходного кода SAST.
40. Протокол испытаний функций информационной безопасности на соответствие СТ РК ISO/IEC 15408-2-2017.
41. Все указанные документы должны быть действующими и выданными независимыми испытательными лабораториями, аккредитованными в системе аккредитации Республики Казахстан.
42. Более того, отсутствие хотя бы одного документа прямо объявляется основанием для признания участника и предложенного ПО несоответствующими требованиям ТС.
43. По существу участник должен найти не только программное обеспечение, функционально подходящее Заказчику, но именно такой программный продукт, который заранее прошел весь перечисленный комплекс исследований в конкретной системе аккредитации.
44. Это существенно сокращает круг потенциально допустимых программных решений.
45. Просим указать нормативный правовой акт, которым для обычной школьной интерактивной образовательной платформы одновременно установлена обязательность каждого из перечисленных протоколов.
46. Необходимо отдельно обосновать обследование сетевой инфраструктуры именно применительно к стандартному программному продукту.
47. Сетевая инфраструктура конкретной школы и программное обеспечение являются различными объектами исследования.
48. Неясно, как заранее существующий протокол на ПО может гарантировать отсутствие уязвимостей именно в фактической сети конкретного Заказчика.
49. Аналогично протокол процессов обеспечения информационной безопасности по существу характеризует внутренние процессы разработчика, а не измеримые функции товара.
50. Если документ оценивает «строгие внутренние рабочие регламенты разработчика», возникает вопрос, почему потенциальный поставщик должен отвечать за внутренние организационные процедуры третьего лица.
51. Нагрузочное тестирование может быть объективно полезным, однако соответствие возможно подтвердить результатами нагрузочных испытаний самого разработчика, независимым отчетом, демонстрацией или условиями SLA.
52. Обязательная аккредитация лаборатории именно в системе Республики Казахстан требует дополнительного обоснования.
53. Международный производитель может иметь результаты испытаний признанной иностранной лаборатории и при этом объективно соответствовать требованиям безопасности.
54. Анализ исходного кода SAST также является специфической процедурой.
55. Не каждый коммерческий разработчик передает исходный код внешним лабораториям.
56. Участник закупки, не являющийся разработчиком, вообще может не иметь доступа к исходному коду продукта.
57. Следовательно, это требование дополнительно привязывает участника к определенному разработчику и заранее проведенной этим разработчиком процедуре.
58. ТС уже устанавливает TLS не ниже 1.2, хэширование паролей, защиту от XSS, SQL-инъекций, CSRF, двухфакторную аутентификацию, резервное копирование, журналирование и иные конкретные механизмы безопасности.
59. Поэтому необходимость еще пяти отдельных протоколов должна быть соразмерно и отдельно обоснована.
60. Особого внимания требует протокол по СТ РК ISO/IEC 15408-2-2017.
61. В верхней части технической спецификации этот документ фактически вынесен даже в поле национальных стандартов, хотя требование сформулировано не как характеристика товара, а как обязанность участника представить конкретный протокол испытаний.
62. Просим привести данное поле в соответствие с его назначением.
63. Национальный стандарт и документ, который обязан предоставить участник, не являются одним и тем же.
64. Просим исключить из технической спецификации требования, описывающие статус участника, его коммерческие отношения и наличие заранее оформленных документов третьих лиц.
65. Для целей борьбы с контрафактом достаточно требовать законное лицензионное программное обеспечение и возможность документально подтвердить его происхождение при поставке.
66. Возможные доказательства: лицензионный сертификат, электронный ключ, договор, счет, накладная, инвойс, подтверждение из кабинета правообладателя, письмо правообладателя, партнерский сертификат или иной проверяемый документ.
67. Необходимо предоставить участнику право выбора способа подтверждения.
68. Аналогично по информационной безопасности следует установить конкретные функциональные требования и допустить эквивалентные документы подтверждения.
69. Например результаты независимого аудита, сертификат соответствия, отчет по тестированию, декларацию разработчика, результаты penetration testing, SAST/DAST либо иной документ в зависимости от предмета проверки.
70. Требование исключительно пяти заранее существующих протоколов НЦА не должно использоваться в качестве закрытого фильтра допуска.
71. Просим также обратить внимание на дублирование части требований: протоколы испытаний перечислены в основном разделе ТС, а затем отдельные аналогичные условия перенесены в раздел условий к потенциальному поставщику после определения победителем.
72. Необходимо однозначно определить, какие документы представляются с заявкой, а какие только победителем.
73. Противоречивое размещение требований создает риск различного толкования комиссией.
74. При наличии сомнений документы, которые объективно нужны только для исполнения договора, должны быть перенесены на стадию поставки.
75. Просим в окончательной редакции обеспечить технологически нейтральный подход и оценивать прежде всего функциональность, безопасность, лицензионность и качество решения, а не наличие у участника заранее сформированного пакета отношений и документов конкретных третьих лиц.
2. Согласно ТС участник обязан включить в заявку авторизационное письмо производителя, подтверждающее право поставки предлагаемого продукта. При этом письмо должно содержать QR-код, позволяющий Заказчику провести верификацию через официальный сайт.
3. Просим исключить данное требование либо установить альтернативные способы подтверждения законности происхождения и права поставки продукции.
4. Наличие авторизационного письма не является технической, функциональной, качественной или эксплуатационной характеристикой закупаемого товара.
5. Авторизационное письмо характеризует договорные и коммерческие отношения потенциального поставщика с третьим лицом.
6. Производитель вправе самостоятельно определять дилерскую сеть, число партнеров, территории продаж и порядок выдачи писем.
7. Следовательно, производитель может выдать письмо одному потенциальному поставщику и отказать другому, несмотря на возможность второго участника законно приобрести и поставить оригинальный товар.
8. Государственная закупка при такой конструкции становится зависимой от решения субъекта, не являющегося Заказчиком, Организатором или конкурсной комиссией.
9. Дополнительным ограничением является обязательное наличие в письме QR-кода с возможностью проверки информации на официальном сайте.
10. Не каждый производитель применяет QR-верификацию авторизационных писем.
11. У производителя может использоваться электронная почта, реестр партнеров, электронная подпись, номер документа, личный кабинет либо иная технология проверки.
12. Отсутствие именно QR-кода не означает поддельность документа или контрафактность товара.
13. Просим исключить требование к конкретному техническому способу верификации письма.
14. Дополнительно участник должен представить документы, подтверждающие право реализации/распространения продукта, причем ТС содержит формулировку о «БҚ бастапқы кодына авторлық құқық», то есть об авторских правах на исходный код ПО.
15. Просим разграничить право использования, распространения экземпляров программного обеспечения и авторские права на исходный код.
16. Обычный лицензионный поставщик программного обеспечения не обязан обладать авторским правом на исходный код продукта.
17. Авторское право на исходный код, как правило, принадлежит разработчику или правообладателю.
18. Передача конечному поставщику лицензии или права перепродажи программного продукта не предполагает передачу ему исключительных авторских прав на исходный код.
19. Указанное требование может фактически сделать участие возможным преимущественно для самого разработчика либо узкого круга аффилированных субъектов.
20. Просим исключить требование об авторских правах на исходный код либо четко заменить его требованием о наличии законного права поставки/предоставления лицензии.
21. Для иностранного продукта дополнительно требуется документ официального представителя или дистрибьютора на территории Республики Казахстан, подтверждающий право представлять интересы иностранной компании.
22. Данное территориальное условие также просим исключить.
23. Законная продукция может быть приобретена непосредственно у иностранного производителя.
24. Через международного дистрибьютора.
25. Через регионального поставщика.
26. Через законного импортера.
27. Либо самостоятельно ввезена поставщиком после заключения договора.
28. Отсутствие у производителя локального официального представителя не свидетельствует о контрафактности товара.
29. Территориальная привязка к дилеру/представителю именно в Республике Казахстан искусственно исключает альтернативные законные каналы поставки.
30. ТС прямо запрещает замену запрашиваемых авторизационных документов гарантийным письмом участника, в том числе обязательством представить документы после завершения закупки.
31. Заказчик дополнительно поясняет, что документы должны существовать на стадии рассмотрения заявок и подтверждают «правоспособность конкурсанта».
32. Обращаем внимание, что в примечании самой ТС отдельно установлено: в технической спецификации не допускается устанавливать квалификационные требования к потенциальному поставщику.
33. Использование понятия «правоспособность конкурсанта» применительно к документу, который должен представить именно участник в составе заявки, требует отдельного правового и технического обоснования.
34. Если документ служит доказательством правоспособности лица, а не характеристики товара, необходимо объяснить, почему он включен именно в техническую спецификацию.
35. Помимо авторизационных документов ТС устанавливает исключительно широкий пакет испытательных протоколов на программное обеспечение.
36. Участник обязан представить протокол обследования сетевой инфраструктуры.
37. Протокол исследования процессов обеспечения информационной безопасности.
38. Протокол нагрузочного тестирования.
39. Протокол анализа исходного кода SAST.
40. Протокол испытаний функций информационной безопасности на соответствие СТ РК ISO/IEC 15408-2-2017.
41. Все указанные документы должны быть действующими и выданными независимыми испытательными лабораториями, аккредитованными в системе аккредитации Республики Казахстан.
42. Более того, отсутствие хотя бы одного документа прямо объявляется основанием для признания участника и предложенного ПО несоответствующими требованиям ТС.
43. По существу участник должен найти не только программное обеспечение, функционально подходящее Заказчику, но именно такой программный продукт, который заранее прошел весь перечисленный комплекс исследований в конкретной системе аккредитации.
44. Это существенно сокращает круг потенциально допустимых программных решений.
45. Просим указать нормативный правовой акт, которым для обычной школьной интерактивной образовательной платформы одновременно установлена обязательность каждого из перечисленных протоколов.
46. Необходимо отдельно обосновать обследование сетевой инфраструктуры именно применительно к стандартному программному продукту.
47. Сетевая инфраструктура конкретной школы и программное обеспечение являются различными объектами исследования.
48. Неясно, как заранее существующий протокол на ПО может гарантировать отсутствие уязвимостей именно в фактической сети конкретного Заказчика.
49. Аналогично протокол процессов обеспечения информационной безопасности по существу характеризует внутренние процессы разработчика, а не измеримые функции товара.
50. Если документ оценивает «строгие внутренние рабочие регламенты разработчика», возникает вопрос, почему потенциальный поставщик должен отвечать за внутренние организационные процедуры третьего лица.
51. Нагрузочное тестирование может быть объективно полезным, однако соответствие возможно подтвердить результатами нагрузочных испытаний самого разработчика, независимым отчетом, демонстрацией или условиями SLA.
52. Обязательная аккредитация лаборатории именно в системе Республики Казахстан требует дополнительного обоснования.
53. Международный производитель может иметь результаты испытаний признанной иностранной лаборатории и при этом объективно соответствовать требованиям безопасности.
54. Анализ исходного кода SAST также является специфической процедурой.
55. Не каждый коммерческий разработчик передает исходный код внешним лабораториям.
56. Участник закупки, не являющийся разработчиком, вообще может не иметь доступа к исходному коду продукта.
57. Следовательно, это требование дополнительно привязывает участника к определенному разработчику и заранее проведенной этим разработчиком процедуре.
58. ТС уже устанавливает TLS не ниже 1.2, хэширование паролей, защиту от XSS, SQL-инъекций, CSRF, двухфакторную аутентификацию, резервное копирование, журналирование и иные конкретные механизмы безопасности.
59. Поэтому необходимость еще пяти отдельных протоколов должна быть соразмерно и отдельно обоснована.
60. Особого внимания требует протокол по СТ РК ISO/IEC 15408-2-2017.
61. В верхней части технической спецификации этот документ фактически вынесен даже в поле национальных стандартов, хотя требование сформулировано не как характеристика товара, а как обязанность участника представить конкретный протокол испытаний.
62. Просим привести данное поле в соответствие с его назначением.
63. Национальный стандарт и документ, который обязан предоставить участник, не являются одним и тем же.
64. Просим исключить из технической спецификации требования, описывающие статус участника, его коммерческие отношения и наличие заранее оформленных документов третьих лиц.
65. Для целей борьбы с контрафактом достаточно требовать законное лицензионное программное обеспечение и возможность документально подтвердить его происхождение при поставке.
66. Возможные доказательства: лицензионный сертификат, электронный ключ, договор, счет, накладная, инвойс, подтверждение из кабинета правообладателя, письмо правообладателя, партнерский сертификат или иной проверяемый документ.
67. Необходимо предоставить участнику право выбора способа подтверждения.
68. Аналогично по информационной безопасности следует установить конкретные функциональные требования и допустить эквивалентные документы подтверждения.
69. Например результаты независимого аудита, сертификат соответствия, отчет по тестированию, декларацию разработчика, результаты penetration testing, SAST/DAST либо иной документ в зависимости от предмета проверки.
70. Требование исключительно пяти заранее существующих протоколов НЦА не должно использоваться в качестве закрытого фильтра допуска.
71. Просим также обратить внимание на дублирование части требований: протоколы испытаний перечислены в основном разделе ТС, а затем отдельные аналогичные условия перенесены в раздел условий к потенциальному поставщику после определения победителем.
72. Необходимо однозначно определить, какие документы представляются с заявкой, а какие только победителем.
73. Противоречивое размещение требований создает риск различного толкования комиссией.
74. При наличии сомнений документы, которые объективно нужны только для исполнения договора, должны быть перенесены на стадию поставки.
75. Просим в окончательной редакции обеспечить технологически нейтральный подход и оценивать прежде всего функциональность, безопасность, лицензионность и качество решения, а не наличие у участника заранее сформированного пакета отношений и документов конкретных третьих лиц.
