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

Качество коммерческого предложения поставщика напрямую зависит от полноты и точности входных данных. Неполное техническое задание (ТЗ) заставляет исполнителя закладывать риски в цену, упускать важные ограничения или предлагать решение, которое не впишется в производственный процесс. Грамотный запрос сокращает цикл согласования на 30–50 % и исключает переплату за «запас прочности», которого на самом деле не требуется.

Главный принцип: технический запрос должен содержать достаточно информации, чтобы поставщик мог рассчитать стоимость, сроки и ресурсы без уточняющих встреч. Если после получения ТЗ у потенциального подрядчика остаются вопросы «а как же это будет работать в нашей линии?» — запрос составлен недостаточно точно.

Чем технический запрос отличается от технического задания на разработку

Техническое задание (ТЗ) по ГОСТ 19.201 — это документ для исполнителя, который уже выбран и приступает к работе. Он регулирует приёмку, этапы, состав документации и ответственность сторон.

Технический запрос для RFQ (Request for Quotation) — это коммерческий документ. Его цель: получить сравнимые предложения от нескольких поставщиков. Он не фиксирует итоговое решение, а описывает задачу, границы системы и критерии приёмки результата. В RFQ допустимы диапазоны параметров и альтернативные варианты исполнения, которых нет в утверждённом ТЗ.

Практическое различие: в RFQ вы спрашиваете «сколько это будет стоить и за какое время при таких условиях», а в ТЗ — «выполните работу именно так и сдайте в такие сроки».

Обязательная структура технического запроса

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

• Контекст и цель закупки. Что покупается, зачем, в какой проект или производственную линию встраивается. Понимая бизнес-задачу, поставщик может предложить более выгодную архитектуру.
• Функциональные требования. Что система/оборудование/услуга должна делать. Описывайте через сценарии использования (use cases), а не через внутреннюю архитектуру.
• Технические параметры и ограничения. Габариты, вес, потребление, интерфейсы, материалы, класс защиты, температурный диапазон, вибрация, ЭМС — всё, что ограничивает выбор конструкции.
• Интеграционные требования. К чему подключается: механические интерфейсы, протоколы связи, форматы данных, требования к ПО, версии API, стандарты обмена.
• Критерии приёмки и тестирование. Как будет проверяться соответствие: заводские испытания, приёмо-сдаточные на объекте, тестовые наборы, пороговые значения.
• Документация и сопровождение. Комплект поставки документов (паспорт, сертификаты, чертежи, руководства, исходники ПО), обучение, гарантия, постгарантийное обслуживание, SLA.
• Логистика и монтаж. Условия доставки (Incoterms), требования к упаковке, доступ к объекту, окна для монтажа, необходимость согласования с оператором объекта.
• Коммерческие условия. Валюта, НДС, этапы оплаты (предоплата/поэтапная/постоплата), требования к банковским гарантиям, штрафные санкции, срок действия предложения.
• Сроки и этапы. Желаемые даты: поставка, монтаж, пусконаладка, ввод в эксплуатацию. Жёсткие дедлайны и предпочтительные.

Критерии, которые реально влияют на цену и сроки

Не все параметры равнозначны. При составлении запроса выделяйте критического влияния на стоимость:

Параметр	Как влияет на предложение	Что уточнить в запросе
Точность/класс точности	Экспоненциальный рост стоимости при ужесточении допусков	Минимально необходимый класс, возможность смягчения на некритичных узлах
Скорость/производительность	Линейный до точки насыщения, затем скачкообразный	Пиковое и среднее значение, допустимые просадки, режим работы (непрерывный/циклический)
Среда эксплуатации	Выбор материалов, уплотнений, класса защиты, охлаждения	Температура, влажность, агрессивные среды, взрывобезопасность, вибрация
Интеграция с существующим ПО/ПЛК	Может требовать разработки шлюзов, адаптеров, переработки кода	Версии ПО, открытые протоколы, доступ к API, ответственный интегратор со стороны заказчика
Сертификация и согласование	Сроки и стоимость получения сертификатов, экспертиз, допусков	Какие сертификаты обязательны, кто инициирует и оплачивает процедуры
Гарантия и SLA	Влияет на заложенные риски и стоимость сервисного фонда	Срок гарантии, время реакции, время восстановления, штрафы за простой

Если параметр некритичен — указывайте диапазон или пишите «не хуже текущего значения». Жёсткое зафиксированное значение там, где допустим разброс, сужает круг поставщиков и повышает цену.

Чек-лист полноты данных перед отправкой запроса

Пройдитесь по списку перед рассылкой. Отсутствие хотя бы одного пункта из критических почти гарантированно приведёт к уточняющим вопросам или некорректным расчётам.

1. Описана бизнес-задача и место решения в общем процессе.
2. Перечислены все функциональные сценарии (основные, аварийные, сервисные).
3. Заданы граничные технические параметры с единицами измерения и допусками.
4. Указаны все интерфейсы: механические, электрические, программные, протоколы, версии.
5. Приложены референсные чертежи, схемы, фото места установки, отчёты замеров (если есть).
6. Описан порядок приёмки: кто, где, по какой методике, какие документы подписываются.
7. Сформулированы требования к документации и языку документов.
8. Указаны условия доступа к объекту: пропуска, режимы работы, средства подъёма, безопасность.
9. Чётко заданы коммерческие рамки: валюта, НДС, оплата, гарантии, штрафы, срок действия офферты.
10. Назначен единый контактный лицо заказчика для технических уточнений.

Типичные ошибки, делающие предложения некомпарабельными

• Смешивание требований и пожеланий. Не разделяя «обязательно» и «желательно», вы заставляете всех поставщиков ценить максимальную конфигурацию. Разделите требования на обязательные (knock-out) и оцениваемые по шкале.
• Отсутствие сценариев отказов. Если не описано, как система должна вести себя при потере питания, обрыве связи, ошибке датчика — каждый поставщик заложит свой вариант, часто избыточный или несовместимый с вашей политикой безопасности.
• Ссылка на «стандартную комплектацию» без перечня. «Поставка по каталогу» трактуется по-разному. Перечислите позиции: кабели, соединители, крепёж, ПО, лицензии, инструмент, запасные части.
• Игнорирование существующей инфраструктуры. Неуказанные ограничения по питанию (фазность, сечение, резервирование), сети (VLAN, пропускная способность, задержка), месту установки приводят к переработкам на монтаже.
• Нечёткие критерии приёмки. «Система должна работать стабильно» — некритерий. «MTBF не менее 50 000 часов», «время восстановления после аварии < 5 мин», «пропускная способность ≥ 1000 шт/ч приreject rate < 0,5 %» — критерии.
• Запрос цены без структуры. Просите разбивку: оборудование, ПО, монтаж, пусконаладка, обучение, документация, доставка, сервисный фонд. Без структуры нельзя понять, где заложен риск, а где — наценка.
• Слишком короткий срок на подготовку предложения. Сложное нестандартное оборудование требует 2–3 недель на расчёт. Недельный дедлайн отсекает квалифицированных поставщиков и привлекает тех, кто даст «цену от балды».

Сценарии: как адаптировать запрос под тип закупки

Закупка стандартного каталогового оборудования

Достаточно указать модель/артикул, количество, условия доставки и оплату. Техническая часть сводится к подтверждению совместимости с существующими системами (напряжение, интерфейсы, габариты). Приложите фото места установки и схему подключения — это исключит ошибки в комплектации кабелей и крепёжа.

Закупка нестандартного/дорабатываемого оборудования

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

Комплексная поставка «под ключ» (EPC/подряд)

Запрос должен содержать: ТЗ на объект, требования к подрядчику (лицензии, допуски, штат, опыт похожих объектов), график этапов, порядок согласования ППР/ПОС, процедуру приёмки объектов, требования к субподрядчикам. Добавьте требование предоставить предварительный календарный план и структуру ЦСМР (цены на этапы).

Закупка услуг (инженерные, сервисные, консалтинг)

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

Как оценить полученные предложения: критерии сравниваемости

После получения офферт приведите их к единому знаменателю перед сравнением цен:

• Нормализуйте валюту и НДС к единой базе.
• Выделите стоимость опций, которые запросили как «желательные», и сравнивайте базовую конфигурацию.
• Приведите сроки оплаты к единому NPV (чистой приведённой стоимости) при вашей ставке дисконтирования — разница в условиях оплаты может составлять 5–15 % от цены.
• Проверьте соответствие knock-out требованиям: предложения, не покрывающие обязательные пункты, отклоняйте без оценки цены.
• Сравните состав документации, гарантийные обязательства, SLA, состав сервисного фонда.
• Оцените риски сроков: реалистичен ли график, есть ли буферы, как поставщик планирует управлять рисками поставки компонентов.

Используйте матрицу взвешенных критериев: цена (обычно 30–50 %), сроки (10–20 %), техническое соответствие (20–30 %), надежность поставщика/сервис (10–20 %). Веса фиксируйте до открытия конвертов.

Практический следующий шаг

Подготовьте шаблон технического запроса под ваши типовые закупки. Включите в него все обязательные разделы, чек-лист полноты и таблицу весовых коэффициентов для оценки. Сохраните как корпоративный стандарт — это исключит вариативность подготовки разными закупщиками и ускорит процесс в 2–3 раза.

Перед следующей закупкой: соберите входные данные по чек-листу, зафиксируйте knock-out требования, согласуйте критерии приёмки с эксплуатацией и безопасностью, выделите контактное лицо для уточнений. Отправьте запрос минимум за 2 недели до дедлайна предложений для стандартного оборудования и за 3–4 недели — для нестандартного.

FAQ

Нужно ли присылать черновики ТЗ поставщикам на этапе RFQ? Если у вас есть утверждённое ТЗ — да, приложите его как приложение. Если ТЗ ещё не готово — отправьте функциональное описание и технические границы; ТЗ будет результатом работы с выбранным поставщиком.

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

Что делать, если поставщики задают много одинаковых уточняющих вопросов? Это признак неполного запроса. Соберите вопросы, дайте официальные ответы рассылкой всем участникам (Q&A protocol), обновите версию запроса с версионированием и продлите срок подачи предложений минимум на неделю после рассылки прояснений.

Стоит ли запрашивать цену на сервисное обслуживание на 3–5 лет вперёд? Да, если оборудование критическое. Просите прайс на типовые работы (ТО, ремонт, замена узлов) и стоимость рекомендуемого сервисного фонда. Это позволяет оценить TCO (общую стоимость владения), а не только CAPEX.

Как поступить, если ни одно предложение не покрывает все обязательные требования? Два пути: (1) пересмотреть knock-out список — возможно, часть требований завышена и может быть смягчена без потери функционала; (2) провести технический диалог с 2–3 лучшими поставщиками для понимания, что именно блокирует соответствие, и скорректировать запрос для повторной процедуры.

Материал носит информационный характер и не заменяет консультации с юристами, закупщиками и техническими экспертами по конкретному объекту закупки. Коммерческие условия, требования к гарантиям и ответственности сторон должны согласовываться с правовым отделом заказчика с учётом действующего законодательства и корпоративных стандартов.