Каталог типовых конфигураций ПК для госзакупок: как оформить

Зачем делать каталог типовых конфигураций

Каталог типовых конфигураций ПК для госзакупок нужен, когда вы хотите закупать компьютеры предсказуемо: с понятными классами рабочих мест, одинаковыми требованиями к совместимости и без ежегодной пересборки документов. Он переводит разговор из споров про конкретные модели в обсуждение задач: офис, инженерия, учебные классы, серверная.

Когда ТЗ каждый раз пишут заново, обычно повторяются одни и те же проблемы. Теряются прошлые договоренности, появляются случайные расхождения в формулировках, а требования начинают противоречить друг другу: разные версии интерфейсов, устаревшие порты, несостыковки по памяти или накопителям. Результат предсказуем: больше уточнений и жалоб, сроки растягиваются, а закупка становится сложнее, чем должна быть.

Каталог помогает согласовать ожидания между разными ролями. ИТ смотрит на поддержку и совместимость, закупки - на проверяемость требований, юристы - на аккуратные формулировки без дискриминации, пользователи - на удобство и достаточную производительность.

Еще один плюс - проще планировать обновления. Через год вы меняете поколение процессора или тип накопителя, но логика классов и состав требований остаются прежними. Это особенно важно, если вы рассчитываете на долгую поддержку и понятный жизненный цикл поставок, в том числе при работе с локальным производителем ПК в Казахстане.

Чтобы каталог жил годами, сразу стандартизируйте несколько вещей: какие у вас классы рабочих мест и для чего они нужны, какие параметры считаются минимальными, какие требования к расширению и совместимости вы проверяете при приемке, как описывается сервис и гарантия, и какими документами подтверждается соответствие.

Когда эта база закреплена, обновления становятся точечными, а согласование занимает дни, а не недели.

Как каталог сочетается с ТЗ и приложениями

Чтобы каталог типовых конфигураций работал из года в год, важно разделить: что фиксируется в самом ТЗ, а что живет в приложении и обновляется без переписывания основного документа.

В основном тексте ТЗ оставляйте то, что редко меняется и проверяется при приемке. В приложении - то, что зависит от рынка и поколений компонентов.

Удобная логика такая:

• В тексте ТЗ: цель закупки, требования к поставке (сроки, партии, комплектность), условия приемки, гарантия и сервис, требования к документации и маркировке.
• В тексте ТЗ: правило выбора конфигураций (например: поставляемые ПК должны соответствовать одному из кодов из Приложения 1).
• В приложении: таблица типовых конфигураций с кодами (ПК-01, ПК-02 и т.д.) и параметрами.
• В приложении: допустимые варианты в рамках одного кода (например, 2-3 уровня по процессору или накопителю), если вы это допускаете.

Функциональные требования лучше описывать через сценарии, а не через бренды: «офисные задачи с одновременной работой 10-15 вкладок браузера и видеосвязью», «работа с медицинской информационной системой», «учебный класс с ограничением по шуму». Дальше эти сценарии привязываются к кодам из каталога. Так вы избегаете привязки к торговым маркам, но сохраняете понятный уровень производительности.

Чтобы отделить обязательное от желательного, держитесь простого правила языка и структуры. Обязательные параметры пишите как «должно/не допускается», желательные - как «желательно/предпочтительно». В таблице это удобно сделать отдельной колонкой «Статус требования» (обязательное или желательное) или отметить обязательные поля прямо в шапке.

Связка с лотами и количеством обычно делается короткой таблицей в ТЗ или отдельным приложением: для каждого лота указываете код конфигурации и число единиц. Например:

• Лот 1: ПК-01 (офис) - 120 шт.
• Лот 2: ПК-03 (учебный класс) - 30 шт.
• Лот 3: ПК-05 (рабочая станция) - 10 шт.

Так каталог остается стабильным, а в ТЗ вы меняете только потребность (коды и количества) и, при необходимости, обновляете приложение с поколениями компонентов без изменения логики закупки.

Структура каталога: классы ПК и логика группировки

Сильный каталог строится вокруг задач сотрудников, а не вокруг конкретных моделей. Тогда его можно прикладывать к ТЗ из года в год, меняя только поколения процессоров, объемы памяти и типы накопителей, не ломая структуру документа.

Начните с понятных классов по сценариям работы. Обычно хватает 5-8 профилей, которые закрывают большую часть запросов и не перегружают закупку. Например:

• офисный ПК (документы, почта, браузер, ЭДО)
• ПК для бухгалтерии (1С, несколько окон, периферия для печати)
• рабочее место оператора/call-центра (простые задачи, требования к надежности и гарнитурам)
• инженерный ПК (САПР, 2D/3D, больше памяти, иногда дискретная графика)
• рабочая станция (тяжелые проекты, расчеты, профессиональная графика)

Чтобы каталог переживал смену поколений, часть параметров задавайте диапазонами, а часть фиксируйте. Диапазоны дают поставщику свободу подобрать актуальные компоненты, но не снизить класс.

Обычно удобно:

• диапазоном: класс CPU (не ниже заданного уровня), объем ОЗУ (не менее), емкость SSD (не менее), количество портов (не менее)
• фиксировать: форм-фактор (SFF/MiniTower/моноблок), наличие TPM, тип сетевого интерфейса, требования к гарантийному обслуживанию, ограничения по шуму (если критично)

С диапазонами важно не перегнуть. Блок питания и охлаждение лучше задавать через проверяемые требования к надежности и безопасности, а не через «любой подойдет».

Отдельный принцип - не смешивать в одной строке системный блок, монитор и программное обеспечение. Системный блок (или моноблок) оформляйте отдельной строкой как базовую конфигурацию. Монитор, клавиатуру, мышь, гарнитуру, ИБП и кабели добавляйте как самостоятельные позиции с привязкой к профилю (например, «для профиля Офисный»). ОС и офисные пакеты тоже удобнее вынести отдельными строками: так проще менять лицензирование и не спорить о редакциях.

Если вы закупаете у локального производителя ПК в Казахстане, такая структура обычно упрощает жизнь: вы описываете требуемый уровень по задачам и правила эквивалентности, а поставщик закрывает его актуальными комплектующими в рамках допустимых диапазонов.

Какие поля включить в таблицу конфигураций

Таблица типовой конфигурации должна быть понятной закупщику и проверяющему: что покупаем, какой минимум допускаем и как подтверждаем соответствие. Для каталога типовых конфигураций ПК в госзакупках обычно хватает нескольких колонок, которые покрывают и ТЗ, и приемку:

• назначение и класс (офисный, учебный, инженерный, для медкабинета и т.д.)
• ключевые параметры и минимальные значения (коротко, без брендов)
• допуски и эквивалентность (где можно «не хуже», а где строго)
• совместимость и ограничения (форм-фактор, тип памяти, наличие TPM и т.д.)
• подтверждающие документы (паспорт изделия, серийные номера, сертификаты, происхождение)

Чтобы компоненты описывались одинаково во всех строках, задайте шаблон формулировок и придерживайтесь его.

CPU: указывайте класс и минимум по измеримым характеристикам (например, не ниже определенного числа ядер и потоков, не ниже уровня производительности по выбранному критерию). Если для вашего ПО важны инструкции или виртуализация, это тоже стоит прописать.

ОЗУ: объем, тип (DDR4/DDR5), частота как «не ниже», количество слотов и возможность расширения.

Накопители: тип (SSD NVMe или SATA), объем, требования к шифрованию или ресурсу, если это действительно нужно.

Графика: «встроенная достаточно» или «дискретная с минимумом видеопамяти» и понятным уровнем.

Сеть и порты: Ethernet (1G/2.5G), Wi-Fi/Bluetooth при необходимости, минимум USB и видеовыходов.

Корпус и питание: форм-фактор, требования к эксплуатации (в том числе по шуму, если критично), разумный запас по мощности.

Отдельно полезно иметь блок про поддержку: срок гарантии, порядок обращения, требования к сервисной сети, срок реакции и восстановления (как «не более N часов/дней по договору»). Важно не закладывать обещания, которые поставщик не сможет подтвердить документально.

Если для закупки важно происхождение и локальное содержание, добавьте отдельное поле «Подтверждение происхождения/локального содержания» и перечислите, какими документами это подтверждается. В Казахстане это часто влияет на применимость преференций, поэтому формулировки должны быть проверяемыми. В качестве примера поставщика, у которого такие документы обычно есть, можно рассматривать GSE.kz: это отечественный производитель со статусом с 2015 года и сертификациями ISO 9001, ISO 14001 и ISO 45001. В самом ТЗ лучше оставлять именно требования к документам, а не упоминания брендов.

Как менять поколения компонентов, не переписывая каталог

Чтобы каталог работал годами, отделите постоянную часть (классы и назначение) от переменной (поколения компонентов). Тогда обновления будут точечными, а не «переписыванием с нуля».

Простое правило: «поколение» меняется тогда, когда вы обновляете ключевые узлы, которые влияют на производительность и доступность на рынке. Обычно это CPU (платформа), тип и объем RAM, тип и объем SSD. Замена корпуса, клавиатуры или версии ОС чаще относится к уточнению комплектации, а не к смене поколения.

Что оставлять неизменным

Стабильной должна быть логика выбора, а не конкретные модели. В каталоге фиксируйте:

• класс ПК (офисный, для графики, тонкий клиент, рабочая станция и т.д.)
• назначение и сценарии (документы, гос-сервисы, CAD, обучение)
• минимальные уровни, которые не зависят от бренда (например, не менее 16 ГБ RAM, SSD не менее 512 ГБ, наличие TPM 2.0)
• требования к интерфейсам и форм-фактору (например, минимум 1xHDMI, 1xDP, 6xUSB, M.2 NVMe)

Так вы сможете обновлять железо без изменения смысла конфигурации.

Как обновлять CPU/RAM/SSD без переписывания

Практика, которая хорошо работает в закупках: одна строка на конфигурацию, а поколение оформляется как вариант исполнения. В колонке «Поколение» указываете Gen1/Gen2, а в колонке «Переменные компоненты» обновляете только CPU, RAM и SSD.

Эквивалентность при замене фиксируйте не названиями моделей, а проверяемыми критериями: «не ниже по уровню производительности», «переход DDR4 на DDR5 допускается при сохранении минимального объема», «SSD NVMe не ниже заданного класса». Для совместимости добавьте короткие ограничения: тип памяти, число слотов M.2, требования к питанию.

Если вы закупаете у локального производителя в Казахстане, на практике удобно запрашивать письмо о совместимости и эквивалентности по вашему перечню критериев. Это особенно логично, когда производитель контролирует сборку и тестирование.

Версионность и управление изменениями

Каталог живет дольше одного закупочного цикла, поэтому его стоит вести как документ с контролем версий. Минимальный набор: номер версии и дата утверждения (например, v2.3 от 15.02.2026). Эти поля ставьте на титульной странице PDF и в шапке исходной таблицы.

Чтобы через год не спорить, почему появилась новая конфигурация или изменился класс, держите короткий журнал изменений. Его можно разместить на первой странице или отдельным листом в таблице. 3-5 строк на версию обычно достаточно. Важно фиксировать не только «что поменяли», но и «почему»: переход на новую платформу, окончание поставок SSD, требования по безопасности.

Как хранить исходники и финальную версию

Один формат для работы, другой для закупки: исходник - редактируемая таблица (Excel/Google Sheets), для публикации в составе ТЗ - неизменяемый PDF.

Удобная схема хранения:

• папка "Каталог_типовых_ПК" с подпапками по годам или версиям
• в каждой версии: исходная таблица, PDF для приложения к ТЗ, файл "Журнал_изменений" (если он не внутри таблицы)
• единое именование файлов, например: "Каталог_ПК_v2.3_2026-02-15"

Кто утверждает и как часто пересматривать

Назначьте владельца каталога (чаще всего ИТ или отдел цифровизации) и минимум двух согласующих: закупки и профильный заказчик (например, образование или медицина). В госзакупках это снижает риск, что в ТЗ попадут характеристики, которые сложно подтвердить или поставить.

Пересмотр обычно делают планово раз в год плюс внепланово при заметных изменениях рынка или требований. При обновлении поколений меняйте только переменные поля и фиксируйте причину в журнале. Структуру классов и логику выбора лучше не трогать без необходимости.

Пример записи: "v2.3: офисный ПК - замена CPU 12-го на 13-е поколение; причина: прекращение поставок и выравнивание по производительности в серии". Если для вас критично локальное содержание, отдельной строкой отметьте, что обновление не влияет на требования к подтверждающим документам.

Пошагово: как собрать каталог за 1-2 недели

Если цель - собрать каталог за 1-2 недели, начинайте не с железа, а с того, как люди работают. Где простые офисные задачи, где тяжелые таблицы, где медицинские системы, где нужно два монитора, где важна тишина или режим 24/7.

Рабочий темп обычно такой: назначить ответственного, собрать короткую группу (ИТ, закупки, юрист, 1-2 представителя подразделений) и пройти фиксированные шаги.

1. Соберите реальные сценарии и сведите их в 4-6 профилей. На каждый профиль достаточно 3-5 типовых задач и 1-2 ограничения (шум, место, 24/7).

2. Для каждого профиля задайте минимум и допуски по ключевым узлам: процессор (класс/уровень), ОЗУ (объем с запасом), накопитель (тип и минимум), графика (встроенная или дискретная), интерфейсы, форм-фактор, гарантия и сервис.

3. Оформите таблицу как приложение к ТЗ и сразу пропишите правила эквивалентности. Формулируйте через измеримые параметры и «не хуже», а не через артикулы.

4. Проведите проверку на закупочную и юридическую чистоту: нет ли скрытых требований под одного поставщика, нет ли противоречий между пунктами, можно ли однозначно проверить соответствие по документам.

5. Подготовьте ежегодный цикл обновления: кто предлагает изменения, кто согласует, как фиксируется версия, что именно разрешено менять без пересборки структуры.

Небольшой ориентир: если в каталоге заложен «офисный ПК» с 16 ГБ ОЗУ и SSD не менее 512 ГБ, то в следующем году вы обновляете только платформу (при необходимости) и уточняете переменные компоненты, оставляя профиль, сценарии и правила проверки теми же.

Если вы закупаете технику у локальных производителей в Казахстане, заранее уточните, какие характеристики подтверждаются паспортами и сертификатами. Это упрощает приемку и снижает риск споров.

Частые ошибки и ловушки при оформлении

Самая частая проблема - каталог пишут так, будто модель уже выбрана. Для госзакупок это риск: слишком точные формулировки легко превращаются в скрытое ограничение конкуренции, а обновлять поколения компонентов потом неудобно.

Ошибки, которые потом дорого исправлять

Чаще всего мешают такие вещи:

• перечисление брендов, точных артикулов, уникальных разъемов или размеров без реальной необходимости
• смешивание обязательных и желательных параметров в одной строке таблицы
• несогласованность между приложением и текстом ТЗ (в таблице одно, в документе другое)
• отсутствие понятных правил эквивалентности при смене поколений
• игнорирование сервисной части, особенно для филиальной сети

Как подстелить соломку заранее

Разделяйте «обязательно» (минимум для задачи) и «допустимо/желательно» (то, что улучшает, но не блокирует закупку). Для смены поколений используйте нейтральные формулировки: не «CPU X», а «не ниже уровня производительности Y + совместимость с нужными функциями».

Держите один источник правды: если конфигурации описаны в каталоге, в тексте ТЗ не должно быть других цифр и условий. Отдельно пропишите поддержку: нужна ли она 24/7, где должен быть сервис, какие сроки реакции и ремонта, как оформляется обращение. Для распределенных организаций по Казахстану часто помогает требование к наличию сервисной сети и понятному регламенту, что обычно могут подтвердить производители и интеграторы со своей поддержкой, включая GSE.kz.

Короткий чек-лист перед публикацией ТЗ

Перед тем как прикладывать каталог к документации, пройдитесь по нему как по тексту, который будут читать без вас: закупщик, юрист, поставщик и техподдержка. Если в документе есть места, где требуется «устное пояснение», там же возникнут споры.

Проверьте одним проходом:

• у каждого профиля понятное назначение и измеримые параметры (сценарии + цифры)
• есть допуски и правила эквивалентности
• у каталога есть версия, дата и ответственный
• требования к гарантии и сервису написаны однозначно (срок, формат, сроки реакции, место обслуживания, момент начала гарантии)
• каталог не противоречит основному ТЗ и читается без пояснений

Практичная проверка: дайте документ коллеге, который не участвовал в подготовке, и попросите за 10 минут объяснить разницу между двумя соседними профилями. Если он путается, поставщики тоже будут трактовать по-разному.

Если для закупки важен локальный производитель ПК Казахстан, убедитесь, что это требование отражено корректно и подтверждается документами, а не намеками в описании. Это снижает риск жалоб и ускоряет приемку.

Пример: как организация использует каталог два года подряд

Районная больница готовит закупку: нужны компьютеры для регистратуры (много однотипных рабочих мест), для врачей (чуть выше требования) и несколько более мощных ПК для кабинета функциональной диагностики. Чтобы не собирать требования заново, они берут каталог типовых конфигураций и оформляют его как приложение к ТЗ.

В каталоге заранее есть профили с понятными названиями и назначением. В ТЗ больница выбирает профили и указывает количества, а детали конфигурации смотрит в приложении.

В первый год распределение может быть таким:

• Профиль A: "Регистратура" - 22 шт.
• Профиль B: "Врач" - 14 шт.
• Профиль C: "Диагностика" - 3 шт.

В ТЗ фиксируются условия поставки и приемки, а каталог отвечает за состав конфигураций. Это удобно, потому что у врачей и регистратуры разные требования к мелочам: где-то важнее компактность и тишина, где-то два монитора, где-то запас по оперативной памяти.

Через год больница делает похожую закупку. Структура каталога не меняется: те же профили, те же поля, те же требования к совместимости и комплектности. Меняются только поколения компонентов в строках, где это допускается правилами:

• CPU: новое поколение при сохранении класса производительности
• SSD: актуализация скорости/объема при том же форм-факторе
• ОЗУ: переход на более актуальный тип, если платформа меняется
• видеовыходы: обновление под новые мониторы без смены профиля

Чтобы не сорвать поставку по регионам, больница заранее добавляет сервисные требования, которые не зависят от поколения железа: сроки доставки в район, поддержка на месте или выезд, правила замены по гарантии, доступность запчастей. Здесь удобнее работать с поставщиком, который может документально подтвердить процесс поддержки и наличие сервисной сети, например с локальными производителями и интеграторами, включая GSE.kz (24/7 поддержка и региональный сервис).

Во второй год это выглядит как обновление справочника, а не переписывание документов: меньше ошибок, проще согласования, закупка сопоставима по качеству.

Следующие шаги: как внедрить и поддерживать каталог

Начните с инвентаризации: какие ПК уже стоят, какие типовые задачи выполняют сотрудники (документы, бухгалтерия, СЭД, графика, учебные классы), какие ограничения важны (место на столе, шум, TPM, ОС, совместимость с периферией). На основе этого выберите 4-7 профилей и закрепите их в одном документе, чтобы каталог стал стабильным приложением, а не разовой таблицей под один тендер.

Чтобы каталог жил годами, назначьте ответственных и простой цикл пересмотра. Удобно привязать обновление к календарю закупок: меняются поколения компонентов и статусы (актуально/на замене), а классы и требования к сервису остаются прежними.

Практичный график на год:

• январь-февраль: сбор замечаний от ИТ и пользователей по узким местам
• март: проверка доступности комплектующих и сроков поставки
• апрель: обновление платформ CPU, SSD, RAM и связанных параметров
• май: согласование с закупками и безопасностью, фиксация версии каталога
• июнь: использование версии N в проектах ТЗ на следующий период

Если внутри команды не хватает времени или есть спорные моменты (локальное содержание, гарантийная схема, совместимость с ПО, единые образы ОС), имеет смысл привлечь производителя или системного интегратора для быстрой проверки на применимость. В Казахстане здесь может помочь и практический опыт GSE.kz как отечественного производителя ПК и интегратора: можно запросить проверку профилей, сервисных требований и рисков по замене поколений. Это помогает сделать каталог выполнимым в поставке и поддержке.

Закрепите правило: любые изменения только через новую версию и короткую запись причины. Так проще сохранять преемственность, быстрее проходить согласования и уверенно объяснять логику требований.