Внимание! Соединение с приложением прервано. Дождитесь повторного подключения.
Обсуждение документации - Просмотр сообщения № 1068724
Тема сообщения
Нарушение законодательства по закупкам (Растрата и возможное хищение бюджетных средств!)
Тип сообщения
Замечание к АД
Поставщик
Товарищество с ограниченной ответственностью "SilkTech"
Представитель поставщика
ОМИРБЕКОВ САЙЛАУ ЖАКЫПБЕКОВИЧ
Дата и время отправки сообщения
2026-09-24 22:57:17
Текст сообщения
ЗАМЕЧАНИЯ
1. В технической спецификации имеются признаки описания заранее определенных программных и аппаратных экосистем. Наиболее очевидный пример — МФУ, где прямо названы Canon PRINT Business и uniFLOW Online. Независимо от использования слова «или эквивалент» в иных местах, требование поддержки продуктов конкретной экосистемы фактически ориентирует закупку на ограниченный модельный ряд.
Просим исключить фирменные наименования и использовать только функциональные требования.
2. Аналогичные признаки присутствуют в спортивном комплексе. В ТС фактически приведена готовая инженерная схема будущего устройства, включая двухроликовую кинематику, материал роликов, коэффициент трения, DC/BLDC-приводы, PWM, двухосевой подвес, 36-вольтовую аккумуляторную систему, 10S, BMS, 42-вольтовое зарядное устройство, конкретную логику мобильного приложения и даже пример имени Wi-Fi-сети.
Подобное описание больше соответствует конструкторской документации конкретного изделия, чем функциональной закупочной спецификации.
3. Просим установить только:
— диапазон скоростей;
— направление и траекторию;
— автоматическую серийную подачу;
— возможность изменения вращения мяча;
— минимальную автономность;
— дистанционное управление;
— средства аварийной остановки;
— безопасность пользователя.
4. Требование корпуса, выдерживающего прямой удар мяча со скоростью не менее 100 км/ч без «царапин и деформаций», объективно трудно проверить при приемке без проведения разрушительного либо потенциально повреждающего испытания.
Просим заменить на требование достаточной механической прочности корпуса согласно документации производителя.
5. Нельзя объективно проверить и обязательную динамическую балансировку роликов через критерий отсутствия «посторонних вибраций или ударов» в диапазоне 1000–4000 об/мин без специального измерительного оборудования и установленного допуска вибрации.
Просим исключить либо установить измеримый критерий.
6. Требование снижения оборотов ролика при прохождении мяча максимум на 5% также требует тахометрирования в динамике и не связано напрямую с точностью тренировки. Просим исключить.
7. В образовательном ПО спецификация переходит от пользовательских функций к архитектуре исходного кода и DevOps-инфраструктуры: 18 сервисов, reverse proxy, алгоритмы балансировки, API, конкретные системные логи, резервирование, SAST.
Указанные характеристики невозможно достоверно установить по обычной технической документации готового продукта без доступа к внутренней документации разработчика.
8. Просим сформулировать требования, которые Заказчик способен проверить при приемке посредством штатного пользовательского интерфейса.
9. Аналогично не может объективно проверяться требование, что система «увеличит интерес учащихся» или позволит готовить материалы максимум за 15 минут. Это зависит от пользователя.
10. Требование 100% одновременного вовлечения класса также является результатом методики проведения урока, а не свойством ПО.
11. Для датчиков техническая спецификация фактически определяет программный стек разработчика: WebSocket RFC 6455, JSON, открытая ОС приемника, web-server, WebSocket-server, Dark Theme, Grid-layout.
Просим исключить стек и оставить возможность визуализации показаний в браузере с заданной максимальной задержкой.
12. Особое ограничение — строго заданная структура интерфейса датчиков, вплоть до расположения номера канала, пиктограммы и состояния НЕАКТИВЕН.
Различный дизайн не влияет на измерение физических величин.
13. В электрической системе также закреплена архитектура умного дома, хотя предмет заявлен как «система электрической безопасности». В техническое задание включены камера, ночное видение, двусторонняя аудиосвязь, push-уведомления, локальная запись, удаленное управление через интернет, погодные сценарии и управление по восходу/закату.
Просим исключить функции, не связанные непосредственно с электробезопасностью.
14. Для предотвращения перегрузки и короткого замыкания достаточно сертифицированных защитных аппаратов. Наличие камеры, микрофона, облачной платформы и погодных сценариев является дополнительным функционалом и существенно сужает рынок.
15. Требование единой мобильной экосистемы производителя препятствует предложению открытых стандартных решений. Просим допустить систему с локальным сервером либо web-интерфейсом без обязательного облачного приложения.
16. Положение о полном русском переводе мобильного приложения также может исключить международные решения с английским интерфейсом. Если русский язык принципиален, просим ограничить требование ключевыми пользовательскими функциями.
17. Авторизационные требования в совокупности с протоколами NCA образуют фактически закрытый перечень документов, который может соответствовать заранее подготовленному продукту.
Просим Заказчика подтвердить наличие на рынке минимум двух независимых образовательных платформ разных разработчиков, уже обладающих всеми указанными документами.
18. Если таких продуктов менее двух, просим исключить уникальные требования.
19. Особое внимание просим обратить на требование актуального протокола исследования сетевой инфраструктуры. Сетевая инфраструктура школы может существенно отличаться от лабораторной сети разработчика, поэтому наличие такого протокола не гарантирует защищенность фактического внедрения.
20. Более рациональным является проведение обследования сети Заказчика после заключения договора и перед вводом системы в эксплуатацию.
21. Аналогично нагрузочное тестирование должно проводиться по конфигурации, фактически развернутой для Заказчика, а не подтверждаться заранее существующим документом неизвестной инфраструктуры.
22. Требование SAST может подтверждать качество разработки, однако оно не должно использоваться как фильтр поставщика, если Заказчик закупает лицензию на готовое ПО.
23. В целом техническая спецификация должна позволять сравнить товары разных производителей по одинаковым измеримым критериям, а не требовать воспроизвести внутреннее устройство одного конкретного решения.
1. В технической спецификации имеются признаки описания заранее определенных программных и аппаратных экосистем. Наиболее очевидный пример — МФУ, где прямо названы Canon PRINT Business и uniFLOW Online. Независимо от использования слова «или эквивалент» в иных местах, требование поддержки продуктов конкретной экосистемы фактически ориентирует закупку на ограниченный модельный ряд.
Просим исключить фирменные наименования и использовать только функциональные требования.
2. Аналогичные признаки присутствуют в спортивном комплексе. В ТС фактически приведена готовая инженерная схема будущего устройства, включая двухроликовую кинематику, материал роликов, коэффициент трения, DC/BLDC-приводы, PWM, двухосевой подвес, 36-вольтовую аккумуляторную систему, 10S, BMS, 42-вольтовое зарядное устройство, конкретную логику мобильного приложения и даже пример имени Wi-Fi-сети.
Подобное описание больше соответствует конструкторской документации конкретного изделия, чем функциональной закупочной спецификации.
3. Просим установить только:
— диапазон скоростей;
— направление и траекторию;
— автоматическую серийную подачу;
— возможность изменения вращения мяча;
— минимальную автономность;
— дистанционное управление;
— средства аварийной остановки;
— безопасность пользователя.
4. Требование корпуса, выдерживающего прямой удар мяча со скоростью не менее 100 км/ч без «царапин и деформаций», объективно трудно проверить при приемке без проведения разрушительного либо потенциально повреждающего испытания.
Просим заменить на требование достаточной механической прочности корпуса согласно документации производителя.
5. Нельзя объективно проверить и обязательную динамическую балансировку роликов через критерий отсутствия «посторонних вибраций или ударов» в диапазоне 1000–4000 об/мин без специального измерительного оборудования и установленного допуска вибрации.
Просим исключить либо установить измеримый критерий.
6. Требование снижения оборотов ролика при прохождении мяча максимум на 5% также требует тахометрирования в динамике и не связано напрямую с точностью тренировки. Просим исключить.
7. В образовательном ПО спецификация переходит от пользовательских функций к архитектуре исходного кода и DevOps-инфраструктуры: 18 сервисов, reverse proxy, алгоритмы балансировки, API, конкретные системные логи, резервирование, SAST.
Указанные характеристики невозможно достоверно установить по обычной технической документации готового продукта без доступа к внутренней документации разработчика.
8. Просим сформулировать требования, которые Заказчик способен проверить при приемке посредством штатного пользовательского интерфейса.
9. Аналогично не может объективно проверяться требование, что система «увеличит интерес учащихся» или позволит готовить материалы максимум за 15 минут. Это зависит от пользователя.
10. Требование 100% одновременного вовлечения класса также является результатом методики проведения урока, а не свойством ПО.
11. Для датчиков техническая спецификация фактически определяет программный стек разработчика: WebSocket RFC 6455, JSON, открытая ОС приемника, web-server, WebSocket-server, Dark Theme, Grid-layout.
Просим исключить стек и оставить возможность визуализации показаний в браузере с заданной максимальной задержкой.
12. Особое ограничение — строго заданная структура интерфейса датчиков, вплоть до расположения номера канала, пиктограммы и состояния НЕАКТИВЕН.
Различный дизайн не влияет на измерение физических величин.
13. В электрической системе также закреплена архитектура умного дома, хотя предмет заявлен как «система электрической безопасности». В техническое задание включены камера, ночное видение, двусторонняя аудиосвязь, push-уведомления, локальная запись, удаленное управление через интернет, погодные сценарии и управление по восходу/закату.
Просим исключить функции, не связанные непосредственно с электробезопасностью.
14. Для предотвращения перегрузки и короткого замыкания достаточно сертифицированных защитных аппаратов. Наличие камеры, микрофона, облачной платформы и погодных сценариев является дополнительным функционалом и существенно сужает рынок.
15. Требование единой мобильной экосистемы производителя препятствует предложению открытых стандартных решений. Просим допустить систему с локальным сервером либо web-интерфейсом без обязательного облачного приложения.
16. Положение о полном русском переводе мобильного приложения также может исключить международные решения с английским интерфейсом. Если русский язык принципиален, просим ограничить требование ключевыми пользовательскими функциями.
17. Авторизационные требования в совокупности с протоколами NCA образуют фактически закрытый перечень документов, который может соответствовать заранее подготовленному продукту.
Просим Заказчика подтвердить наличие на рынке минимум двух независимых образовательных платформ разных разработчиков, уже обладающих всеми указанными документами.
18. Если таких продуктов менее двух, просим исключить уникальные требования.
19. Особое внимание просим обратить на требование актуального протокола исследования сетевой инфраструктуры. Сетевая инфраструктура школы может существенно отличаться от лабораторной сети разработчика, поэтому наличие такого протокола не гарантирует защищенность фактического внедрения.
20. Более рациональным является проведение обследования сети Заказчика после заключения договора и перед вводом системы в эксплуатацию.
21. Аналогично нагрузочное тестирование должно проводиться по конфигурации, фактически развернутой для Заказчика, а не подтверждаться заранее существующим документом неизвестной инфраструктуры.
22. Требование SAST может подтверждать качество разработки, однако оно не должно использоваться как фильтр поставщика, если Заказчик закупает лицензию на готовое ПО.
23. В целом техническая спецификация должна позволять сравнить товары разных производителей по одинаковым измеримым критериям, а не требовать воспроизвести внутреннее устройство одного конкретного решения.
Ответы представителей заказчика и организатора, секретаря
Дата:
2026-10-03 01:17:24
Автор:
САДУОВ СЕРИК ИСЛЯМОВИЧ
Решение:
Отклонить замечания
1. Замечание не принимается. Обоснование: Наименования Canon PRINT Business и uniFLOW Online приведены в технической спецификации исключительно в качестве иллюстративных примеров («мысалы, Canon PRINT Business, uniFLOW Online») функциональной готовности встроенного сетевого контроллера МФУ к сопряжению с мобильными и облачными сервисами. Спецификацией прямо закреплена поддержка открытых отраслевых протоколов сетевой печати (Apple AirPrint, Mopria Print Service, TCP/IP, SMB, IPP, IPSec), что гарантирует технологическую нейтральность и позволяет предложить эквивалентные печатно-сканирующие устройства широкого круга мировых производителей. 2. Замечание не принимается. Обоснование: В соответствии с пунктом 2 статьи 21 Закона РК «О государственных закупках», Заказчик определяет требуемые функциональные, технические, качественные и эксплуатационные характеристики закупаемых товаров исходя из собственных потребностей и специфики образовательного процесса специализированного лицея. Параметры двухроликовой кинематической системы прямого фрикционного разгона, мощности двигателей (не менее 200 Вт каждый), безопасного напряжения 36 В постоянного тока и аккумуляторной батареи (460 Вт·ч) инженерно и методически обоснованы необходимостью точного и стабильного моделирования реальных игровых мячей (силовых, планирующих, крученых) без просадки оборотов при интенсивных серийных тренировках лицейских сборных команд. 3. Замечание не принимается. Обоснование: Установление исключительно общих функциональных ориентиров без четкой фиксации кинематических, электромеханических и энергетических параметров создает критический риск поставки маломощных бытовых тренажеров, не рассчитанных на интенсивную эксплуатацию в условиях спортивных секций лицея, что приведет к преждевременному выходу оборудования из строя и срыву тренировочного процесса. 4. Замечание не принимается. Обоснование: Требование к ударопрочности защитного кожуха (выдерживание прямых ударов волейбольного мяча на скорости до 100 км/ч без образования трещин и деформаций) обусловлено правилами техники безопасности при проведении динамических тренировок в спортивном зале. Соответствие данному требованию подтверждается официальным техническим паспортом изделия, эксплуатационной документацией завода-изготовителя (datasheet) и сертификатами на применяемые конструкционные материалы (ABS-пластик, монолитный поликарбонат). Проведение разрушающих испытаний при стандартной приемке товара не требуется. 5. Замечание не принимается. Обоснование: Динамическая балансировка метательных роликов в диапазоне 1000–4000 об/мин является базовым заводским показателем качества механической обработки вращающихся узлов оборудования повышенной кинетической энергии. Данный параметр подтверждается заводским паспортом изделия и сертификатом качества производителя, а при приемо-сдаточных испытаниях верифицируется визуально-инструментальным методом — плавностью хода и отсутствием паразитных биений и вибраций станины на максимальных рабочих оборотах. 6. Замечание не принимается. Обоснование: Показатель просадки частоты вращения роликов не более 5% при захвате и выталкивании мяча является ключевым физическим критерием стабильности баллистической траектории серийных выстрелов. Превышение данного порога свидетельствует о дефиците крутящего момента двигателей, что приводит к застреванию мячей в раструбе и хаотичному падению дальности бросков. Соответствие обеспечивается установленной мощностью приводов (2х200 Вт) и подтверждается паспортом изделия производителя. 7. Замечание не принимается. Обоснование: Закупаемое программное обеспечение разворачивается в локальной вычислительной инфраструктуре государственного учреждения образования и обрабатывает персональные данные несовершеннолетних лицеистов. Трехуровневая клиент-серверная модель, компонентная изоляция (не менее 18 логических модулей), обратное проксирование (reverse proxy) и статический анализ кода (SAST) являются обязательными требованиями отказоустойчивости и информационной безопасности. Модульная структура гарантирует, что сбой одного функционального блока (например, медиастриминга) не приведет к аварийной остановке работы всей платформы лицея во всех классах одновременно. 8. Замечание не принимается. Обоснование: Соответствие архитектурных и функциональных параметров программной платформы проверяется в ходе штатных приемо-сдаточных испытаний функциональным тестированием пользовательских и административных сервисов через стандартный графический интерфейс, а также верификацией комплектной эксплуатационной документации («Руководства системного администратора»). Предоставление внутренней исходной проектной документации разработчика Заказчику не требуется. 9. Замечание не принимается. Обоснование: Показатель «подготовка интерактивных материалов не более чем за 15 минут» приведен в подразделе «Ожидаемые результаты от внедрения ПО» в качестве качественного методического ориентира эргономической эффективности программного продукта, характеризующего наличие развитой библиотеки готовых дидактических шаблонов, 3D-моделей и интуитивного конструктора уроков. Данный параметр оценивает развитость дидактического инструментария системы, а не индивидуальную скорость работы конкретного преподавателя. 10. Замечание не принимается. Обоснование: Возможность одновременного вовлечения учащихся обеспечивается архитектурой игрового соревновательного модуля платформы: подключение к сессиям викторин и интерактивных опросов осуществляется через стандартные веб-браузеры любых пользовательских устройств учеников (смартфонов, планшетов, моноблоков) путем считывания QR-кода без ограничения числа одновременных участников внутри учебной группы. 11. Замечание не принимается. Обоснование: Сетевые протоколы и архитектурные параметры комплекса датчиков сформированы на основе открытых международных веб-стандартов (IEEE 802.11, WebSocket RFC 6455, JSON). Их применение необходимо для обеспечения прямой трансляции показаний с 15 измерительных каналов лаборатории в стандартные веб-браузеры моноблоков и интерактивных панелей в режиме реального времени без установки сторонних проприетарных драйверов. Темная цветовая схема (Dark Theme) научно обоснована эргономикой зрения: она снижает утомляемость глаз оператора и обеспечивает высокую контрастность графиков при коллективной демонстрации на большом экране с расстояния нескольких метров. 12. Замечание не принимается. Обоснование: Унифицированная сетка (Grid-layout) из 15 информационных карточек обеспечивает одновременное наглядное отображение всех 15 каналов без необходимости вертикальной прокрутки экрана во время фронтального урока. Контрастная индикация статуса «НЕАКТИВЕН» строго на красном фоне обеспечивает мгновенную визуальную диагностику сбоя канала учителем и исключает отображение «зависших» устаревших данных под видом актуальных измерений. Описание интерфейса не содержит указаний на товарные знаки и реализуется стандартными средствами HTML5/CSS/JavaScript. 13. Замечание не принимается. Обоснование: Закупаемый комплекс электрической безопасности предназначен для специализированного учебного кабинета с высокой концентрацией дорогостоящей микроэлектроники и силового оборудования. В школьной аудитории пожарная и электрическая безопасность неразрывно связаны с визуальным контролем обстановки: модуль видеонаблюдения позволяет дистанционно верифицировать признаки искрения, задымления или несанкционированного включения силовых приборов учащимися в отсутствие педагога и принять экстренные превентивные меры. 14. Замечание не принимается. Обоснование: Стандартные защитные аппараты в щитовой не обеспечивают дистанционного селективного обесточивания конкретных рабочих мест, мониторинга энергопотребления отдельных лабораторных линий и автоматизации дежурных режимов освещения. Спецификация базируется на открытых международных стандартах электробезопасности и позволяет предложить сертифицированное оборудование широкого круга производителей, представленных на рынке Республики Казахстан (Aqara, Tuya, Sonoff, Xiaomi Smart Home, Legrand и их эквиваленты). 15. Замечание не принимается. Обоснование: Управление через штатное бесплатное мобильное приложение гарантирует стабильность заводских прошивок, исключает абонентскую плату за базовый функционал и обеспечивает нативную интеграцию с Push-уведомлениями мобильных платформ. При этом базовые защитные алгоритмы розетки и выключателя (аппаратная защита от перегрузок и коротких замыканий) выполняются полностью автономно и локально даже при временном отсутствии внешнего интернета. 16. Замечание не принимается. Обоснование: В соответствии с Законом РК «О языках в Республике Казахстан» и положениями технической спецификации, вся сопроводительная документация, технические паспорта, инструкции и пользовательские интерфейсы поставляемых систем должны поддерживать государственный и русский языки. Использование систем исключительно с иностранным интерфейсом в государственных организациях образования не допускается. 17. Замечание не принимается. Обоснование: На рынке Республики Казахстан представлен ряд образовательных платформ и тиражных цифровых решений отечественных и международных разработчиков интерактивного учебного контента (включая экосистемы BilimLand, Daryn Online, Kundelik и их сертифицированные аналоги), успешно прошедших оценку соответствия в аккредитованных испытательных лабораториях системы Национального центра аккредитации (NCA) РК. Кроме того, Заказчиком во исполнение предписания ДВГА принято решение об исключении требований о том, что авторизационное письмо должно быть адресовано конкурсной комиссии, содержать номер и наименование конкурса, номер лота, а также требования о том, что дата выдачи письма не должна предшествовать дате публикации объявления о проведении текущего конкурса. Потенциальный поставщик вправе предоставить любое действующее официальное дилерское, партнерское или дистрибьюторское соглашение вендора в пределах срока его действия. 18. Замечание не принимается. Обоснование: Установленные требования к программному обеспечению и протоколам безопасности являются обоснованными, базируются на государственных стандартах Республики Казахстан и обеспечивают защиту государственных информационных систем и персональных данных учащихся лицея. Рынок данных решений в РК является конкурентным. 19. Замечание не принимается. Обоснование: Протокол исследования сетевой инфраструктуры подтверждает защищенность клиент-серверного взаимодействия и архитектуры сетевого стека самого программного продукта разработчика (порты, сетевые службы, шифрование трафика, устойчивость к атакам Man-in-the-Middle) в типовых условиях локальных сетей образовательных учреждений, гарантируя отсутствие уязвимостей в кодовой базе до момента инсталляции софта в школьную сеть. 20. Замечание не принимается. Обоснование: Перенос подтверждения защищенности программного обеспечения на стадию приемки создает критический риск поставки уязвимого софта, компрометации локальной вычислительной сети школы и последующего срыва исполнения договора государственных закупок. Подтверждение информационной безопасности на этапе подачи заявок является необходимой превентивной гарантией зрелости тиражного программного продукта. 21. Замечание не принимается. Обоснование: Протокол нагрузочных испытаний аккредитованной лаборатории NCA РК подтверждает предельную архитектурную емкость и масштабируемость программного ядра разработчика (до 1000 активных сетевых соединений), гарантируя отсутствие зависаний платформы при пиковых синхронных срезах знаний и олимпиадах независимо от конкретного школьного сервера. 22. Замечание не принимается. Обоснование: Статический анализ исходного кода (SAST) в аккредитованной лаборатории проводится в условиях государственной аттестации и строгого соблюдения конфиденциальности (соглашения NDA). Данный аудит необходим для подтверждения отсутствия в программном коде скрытых недекларированных возможностей («закладок», вредоносных скриптов, уязвимостей переполнения буфера) и не требует передачи исходного кода Заказчику или поставщику: разработчик заблаговременно организует прохождение плановой сертификации своего продукта, а поставщик предоставляет готовый официальный протокол испытаний. 23. Замечание не принимается. Обоснование: Техническая спецификация сформирована в строгом соответствии с пунктом 2 статьи 21 Закона РК «О государственных закупках» и Правилами осуществления государственных закупок исходя из объективных методических, функциональных и эксплуатационных потребностей специализированного лицея. Все установленные характеристики базируются на открытых отраслевых, национальных и международных стандартах (SELV 36 В, Wi-Fi 802.11, WebSocket RFC 6455, JSON, IP54, ПУЭ РК, СТ РК ISO/IEC 15408-2-2017), не содержат указаний на товарные знаки или конкретных изготовителей и позволяют предложить сертифицированную продукцию широкого круга брендов, представленных на рынке Республики Казахстан. За исключением исключенных требований к реквизитам и дате авторизационных писем (согласно предписанию ДВГА), оснований для изменения параметров технической спецификации не имеется.
