Техзадание на поставку ПК и серверов: структура и параметры

Зачем нужно ТЗ и что обычно идет не так без него

Техзадание на поставку ПК и серверов нужно не для галочки. Оно помогает получить оборудование, которое подойдет вашей ИТ-среде, приедет вовремя, будет корректно укомплектовано и будет понятно, как его поддерживать. Без ТЗ заказ часто превращается в набор обещаний в переписке, а потом - в спор о том, кто что имел в виду.

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

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

Часть требований удобнее описывать словами (сценарии использования, ограничения по помещению, ожидания по сервису), а часть - таблицами (конфигурации, количество, сроки, комплектность, SLA, тесты). Тогда документ остается понятным и для закупки, и для ИТ, и для поставщика, включая производителей и системных интеграторов вроде GSE.kz.

Определяем контур поставки: сценарии, объемы, ограничения

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

Описывайте сценарии группами, а не «всем по одному». Пример: 60 офисных сотрудников (почта, документы, браузер), 10 бухгалтеров (1С и ЭЦП), 6 инженеров (CAD), 2 переговорные (видеоконференции). Для серверов достаточно указать назначение: виртуализация, файловые ресурсы, базы данных, резервное копирование.

Чтобы контур был понятным, ответьте на несколько вопросов:

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

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

Совместимость и требования к существующей ИТ-среде

Перед тем как описывать «железо», зафиксируйте, с чем оно должно работать. В ТЗ полезен короткий блок «текущая среда»: сеть (скорости портов, Wi-Fi), домен и политики, чем управляется парк (AD/GPO, Intune/SCCM или другой инструмент), какая периферия уже есть (принтеры, сканеры, терминалы), какие ОС и лицензии разрешены.

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

Что прописать, чтобы не было конфликтов

Параметры, которые чаще всего влияют на совместимость и итоговую стоимость:

• Разъемы и форм-факторы: видео (HDMI/DP/VGA), USB-C, RJ-45, 2.5/10GbE, 19" стойка и высота сервера, тип рельс.
• Драйверы и ОС: поддержка выбранной версии Windows/Linux, наличие подписанных драйверов, возможность «тихой» установки.
• Управление: поддержка удаленного управления сервером (IPMI или аналог), PXE-загрузка, совместимость с вашим MDM/EDR.
• Инфобезопасность: TPM 2.0, Secure Boot, требования к шифрованию дисков, запрет лишних интерфейсов (если нужно).
• Унификация: допускаемые модели и взаимозаменяемые комплектующие (БП, диски, память), требования к единой партии и маркировке.

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

Параметры ПК и рабочих станций, которые реально влияют

В ТЗ лучше писать не «самый мощный», а «достаточный под задачи». Так проще сравнивать предложения и меньше риск получить устройства не того класса.

Указывайте минимум и рекомендацию. Для офисных задач часто важнее быстрый накопитель, чем максимальный процессор. Для бухгалтерии и работы с большими таблицами обычно критична оперативная память. Для САПР, 3D и видео заранее решите, нужен ли запас по ядрам CPU и по объему RAM.

Чтобы требования можно было проверить, зафиксируйте:

• CPU: класс/поколение или «не ниже» по производительности, при необходимости - ограничения по энергопотреблению.
• RAM: объем, возможность расширения (количество слотов), требование к двухканальному режиму.
• Накопители: тип (SSD/NVMe), объем, при необходимости - второй диск под данные.
• Графика: встроенная или дискретная, количество мониторов, нужные порты (HDMI/DP/USB-C).
• Сеть и безопасность: 1G/2.5G, Wi-Fi/BT при необходимости, обязательность TPM (например, под корпоративные политики).

Отдельно опишите «физику» рабочего места: габариты корпуса, запас по питанию, приемлемый уровень шума для открытого офиса. Если планируете апгрейд через 1-2 года, зафиксируйте доступность слотов и разъемов, а также тип корпуса (SFF или полноразмерный).

Комплектность лучше не оставлять «по умолчанию». Укажите монитор (диагональ, разрешение, тип матрицы), клавиатуру и мышь (тип, раскладка), кабели и переходники. Это особенно важно при массовой поставке (школы, госорганизации), где нужна одинаковая конфигурация и простая замена.

Параметры серверов: производительность, надежность, управление

Сервер нельзя описывать словом «мощный». Начните с назначения: файловые ресурсы, виртуализация, базы данных, прикладные сервисы. Для каждого сценария укажите ожидаемую нагрузку (пользователи, объем данных, число виртуальных машин, рост на 1-3 года) и требования к доступности.

По производительности фиксируйте минимум по CPU, RAM и хранению, но не забывайте про отказоустойчивость. В ТЗ обычно важны RAID-уровни под разные типы данных, диски с hot-swap, запас под расширение, требования к контроллеру (кэш, батарея или суперконденсатор). Если критична скорость, просите не просто «SSD», а понятные метрики: IOPS или минимальную задержку для ключевых томов.

Сеть часто становится узким местом. Укажите количество портов, скорость (1/10/25G), тип (SFP+ или RJ-45) и схему резервирования (LACP, два независимых коммутатора). Отдельно пропишите совместимость по оптике и модулям, чтобы не получить конфигурацию, которую нельзя нормально включить в вашу инфраструктуру.

Форм-фактор тоже влияет на итог: rack или tower, высота в U, рельсы в комплекте, допустимая глубина, питание (1 или 2 БП), тип вилок и требования к PDU.

Для управления добавьте требования:

• удаленная консоль до загрузки ОС (KVM over IP), виртуальные носители;
• мониторинг состояния (температуры, вентиляторы, БП, диски) и журналирование событий;
• роли доступа и, при необходимости, интеграция с вашей учеткой (например, AD);
• уведомления (почта, SNMP) и требования к логам.

Практичный пример: если закупаете 2U rack-серверы под небольшую виртуализацию, сразу просите два блока питания, RAID10 под основные ВМ, отдельный зеркальный том под систему гипервизора и обязательную удаленную консоль. Такие требования легко проверить на приемке, в том числе на моделях уровня GSE S200.

Комплектность, упаковка и логистика без сюрпризов

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

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

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

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

Сервис, гарантия и SLA: фиксируем ожидания заранее

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

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

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

В SLA обычно закрепляют:

• время отклика (когда с вами связались после заявки);
• время восстановления (когда оборудование снова в работе);
• график поддержки (5/2, 24/7);
• окно обслуживания (возможны ли работы ночью или только днем);
• требования к подменному фонду или оперативной замене узлов.

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

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

Сроки, этапность и контроль исполнения

Сроки лучше описывать как план работ, а не одной датой. Это особенно важно, когда часть позиций производится, часть идет со склада, а часть зависит от лицензий и согласований.

Зафиксируйте этапы и результат каждого этапа - так проще контролировать прогресс и быстро понимать причину задержки.

Как задать этапы и даты

Обычно хватает 4-5 вех с понятными критериями готовности:

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

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

Отчетность и контроль исполнения

Сразу пропишите, что поставщик отправляет регулярно и в каком виде:

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

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

Приемочное тестирование: критерии, протоколы, результат

Приемка должна быть описана так же четко, как и характеристики. Иначе спор быстро превращается в «работает у нас» против «не работает у вас».

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

Минимальный набор проверок, который почти всегда дает пользу:

• визуальный осмотр (корпус, пломбы, разъемы, экран);
• первое включение (загрузка без ошибок, корректные показатели BIOS/UEFI);
• сверка конфигурации (CPU, RAM, диски, сетевые порты, блок питания, лицензии);
• проверка совместимости (подключение к сети, вход в домен, работа с периферией, установка драйверов и обновлений);
• для серверов - короткий тест стабильности CPU/RAM/дисков (30-60 минут) и просмотр журналов ошибок.

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

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

Пошаговая структура ТЗ: как собрать документ за 1-2 дня

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

1. Номенклатура. Для каждой позиции укажите роль (офисный ПК, рабочая станция, сервер, монитор), количество, место установки и короткий сценарий (бухгалтерия, CAD, виртуализация).

2. Параметры. Для ПК и серверов задайте обязательные требования и отдельной колонкой - желательные. Вместо общих слов используйте измеримые параметры: CPU, RAM, тип и объем накопителей, сетевые порты, слоты расширения, удаленное управление для серверов, шум и форм-фактор для офисных зон.

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

4. Сервис и SLA. Зафиксируйте сроки реакции и восстановления, часы поддержки, формат обращения и условия замены на время ремонта.

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

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

Частые ошибки в ТЗ и как их избежать

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

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

• Размытые слова вроде «производительный» или «современный». Заменяйте их числами: минимальная производительность/класс CPU, объем ОЗУ, тип накопителя, количество портов, скорость сети.
• Обязательные требования и «хотелки» смешаны. Делите на MUST и SHOULD, иначе поставщик выберет минимально допустимое.
• Комплектность не прописана. Указывайте, что входит в цену: кабели, крепеж, направляющие, ОС, лицензии, драйверы, аксессуары, запасные части, документация.
• Нет приемочных критериев. Сразу закрепляйте: какие тесты, что считается успешным результатом, какие дефекты критичны и какие сроки на исправление.
• Требования не совпадают с реальными условиями. Перед финалом сверяйте питание, розетки и ИБП, размеры и глубину стойки, типы портов на коммутаторах, схемы VLAN, условия охлаждения.

Небольшой пример: вы указали «сервер 2U», но не проверили глубину стойки и тип направляющих. В день монтажа выясняется, что нужны другие рельсы и питание C19, и проект останавливается.

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

Короткий чек-лист перед отправкой ТЗ поставщикам

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

• Сценарии и софт описаны конкретно: кто работает (бухгалтерия, инженер, касса), какие критичные приложения и версии, требования к периферии и ОС.
• Характеристики заданы измеримо и с приоритетами: CPU, RAM, тип и объем SSD, сеть, порты, возможность расширения. Отдельно отмечено, где допустим эквивалент, а где нет.
• Комплектность и документы не оставлены на догадки: кабели, крепеж, рельсы для серверов, драйверы, серийные номера, паспорта, гарантийные документы, маркировка коробок и состав поставки поштучно.
• Сервис зафиксирован заранее: срок гарантии, время реакции, каналы обращения, график поддержки, порядок замены и кто оплачивает выезд/доставку.
• Приемка описана как процесс: какие тесты выполняются, какие протоколы и сроки, что считается несоответствием и какие действия обязательны (замена, доукомплектование, штрафы).

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

Пример: ТЗ для офиса и небольшой серверной

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

Для ПК удобно разбить поставку на профили, чтобы не переплачивать всем одинаково:

• Профиль A: офисные задачи, браузер, почта, 1-2 монитора.
• Профиль B: бухгалтерия, аналитика, тяжелые таблицы, 2 монитора, больше ОЗУ.
• Профиль C: CAD/графика или разработка, дискретная графика и запас по питанию.

Внутри каждого профиля фиксируйте не только «процессор и память», но и то, что влияет на результат: тип и объем SSD, количество видеовыходов, Wi-Fi или только проводная сеть, требования к корпусу (SFF/MT), ОС и способ установки (образ, домен, драйверы).

Для серверов укажите минимум: RAID (уровень и тип контроллера), диски (класс, горячая замена), два блока питания, 2-4 сетевых порта нужной скорости, отдельный порт удаленного управления (IPMI/iKVM), совместимость с гипервизором и существующим сетевым оборудованием.

По срокам опишите этапность: поставка в головной офис и развоз по филиалам, окна приемки, кто отвечает за подъем и распаковку, что считается «поставлено» (серийники, пломбы, кабели, документы).

Приемку за 1-2 дня можно провести без лаборатории, если заранее прописать тесты: сверка комплектности по ведомости и серийным номерам, включение и отсутствие ошибок BIOS/POST, видимость всех дисков и ОЗУ, быстрый стресс-тест CPU/ОЗУ, SMART-проверка SSD, проверка сети (скорость линка, все порты), проверка удаленного управления. Для одного сервера полезно отдельно проверить восстановление RAID и замену диска.

Следующие шаги: как запустить закупку и не потерять контроль

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

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

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

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