Разработка технического задания на КД — под ЕСКД, без переделок

Что вы получаете:

• ТЗ в структуре ЕСКД: состав документации, требования к изделию, критерии приёмки;
• привязку к стадиям разработки и форматам электронных данных;
• согласование с вашим главным конструктором и заинтересованными службами;
• пример структуры ТЗ и чек-лист исходных данных до старта;
• план-график работ и порядок внесения изменений.

Составить самостоятельно или заказать под ключ

Написать ТЗ своими силами реально, когда в штате есть конструктор с практикой ЕСКД и время на сбор требований со всех служб. Без этого документ получается «о продукте вообще», и цена ошибки переезжает в стоимость разработки КД. Сравните:

Самостоятельный путь оправдан для простого изделия с типовым составом КД и живым опытом ЕСКД внутри команды. Во всех остальных случаях ТЗ дешевле заказать, чем переделывать по нему документацию.

Чем рискует проект с некорректным ТЗ

Первая группа рисков инженерная: состав и стадии, противоречащие ЕСКД, означают переделки, срыв сроков и рост затрат, потому что исполнитель формально прав, выдав ровно то, что написано в задании. Вторая группа закупочная: в процедурах по 44-ФЗ и 223-ФЗ двусмысленное ТЗ в документации приводит к жалобам и срыву закупки, контроль здесь ведёт ФАС России.

Третья группа выходит на рынок вместе с изделием. Продукция, спроектированная без учёта обязательных требований технических регламентов ЕАЭС, при выпуске в обращение создаёт риск ответственности по статье 14.43 КоАП РФ; надзор по видам продукции ведут Роспотребнадзор и Ростехнадзор, за участниками подтверждения соответствия следит Росаккредитация.

Две ловушки, снимаем сразу. ТЗ на КД: договорной документ, его утверждает заказчик по согласованию с разработчиком и главным конструктором, обязательных внешних согласований с госорганами у него нет. И второе: ТЗ и ТУ не один и тот же документ. Задание описывает, что и как разработать; технические условия — вид конструкторской документации на готовую продукцию по ГОСТ 2.114-2016, подробнее о них на странице разработки ТУ.

Что такое техническое задание на разработку КД

Документ, который переводит замысел в измеримые требования и назначает правила игры между заказчиком и разработчиком: что проектируем, по каким нормам, какие документы и в каком виде сдаются, как проверяется результат. Требования к содержанию и оформлению ТЗ задаёт ГОСТ 15.016-2016, порядок взаимодействия сторон при постановке продукции на производство описывает ГОСТ Р 15.301-2016.

Рабочая структура ТЗ на КД в логике ЕСКД выглядит так:

• основание и цели работ, состав изделия, область применения;
• нормативные ссылки: стандарты ЕСКД, профильные техрегламенты ЕАЭС, отраслевые нормы;
• требования к изделию: функционал, безопасность, надёжность, технологичность, материалы, маркировка;
• состав сдаваемой документации: чертежи, спецификации, ведомости, пояснительная записка, эксплуатационные документы;
• стадии разработки и критерии готовности на каждой: от эскизного проекта до рабочей документации, если применимо;
• требования к электронным моделям и форматам передачи данных, включая обмен с PLM/PDM;
• порядок контроля и приёмки, состав приёмо-сдаточной документации;
• план-график, зоны ответственности сторон, порядок изменений с реестром.

Каждый пункт пишется проверяемым. «Изделие должно быть надёжным» не критерий; «наработка на отказ не ниже заданной, подтверждается расчётом и протоколом испытаний» уже критерий, по которому можно принимать или возвращать документацию.

Техническое задание на разработку КД: пример структуры

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

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

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

Чем ТЗ на разработку КД отличается от ТЗ на поставку

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

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

Отраслевые сценарии

Машиностроение и металлообработка

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

Электротехника и электроника

В требования входят электробезопасность, схемы и перечни элементов, совместимость с регламентами ЕАЭС по электромагнитной совместимости и низковольтному оборудованию, маркировка. Отдельно фиксируется состав документации на печатные узлы, если они есть в изделии.

Блок-контейнеры и модульные изделия

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

Госзакупки и импортозамещение

Задание пишется языком, который переживёт жалобу в ФАС: без двусмысленностей, с измеримыми критериями приёмки. Для продукции под реестр Минпромторга в ТЗ закладываются требования к происхождению компонентов по постановлению № 719; как устроено подтверждение (акт экспертизы ТПП или сертификат СТ-1) разобрано на странице КД для реестра Минпромторга.

Как мы работаем

1. Бриф и аудит исходных данных. Текущая документация, референсы, ограничения, требования среды и площадки.
2. Нормативная рамка. Фиксируем применимые стандарты ЕСКД и техрегламенты ЕАЭС под ваше изделие.
3. Структура ТЗ. Состав КД, стадии, форматы электронных данных, контрольные точки.
4. Черновик. Конкретизируем требования, критерии приёмки, план-график.
5. Согласование. Сводим замечания служб и разработчика, готовим редакции.
6. Утверждение. Заказчик утверждает ТЗ; фиксируем версию и порядок изменений.
7. Сопровождение. По договорённости участвуем в авторском надзоре на стадии разработки КД по этому ТЗ.

Какие исходные данные понадобятся

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

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

От чего зависит стоимость

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

Базовый проект: простое изделие, стандартные материалы, типовой состав КД. Объём ТЗ минимален, основная работа — грамотно зафиксировать критерии приёмки. Средняя сложность добавляет несколько сборок, требования к испытаниям и электронную модель: растёт раздел требований и состав сдаваемой документации.

Высокая сложность: расчёты, спецматериалы, обязательные требования техрегламентов, интеграция с PLM/PDM и несколько итераций согласований между службами. Госзаказ добавляет свой слой: повышенные требования к формулировкам, обоснованиям и отчётным материалам, где каждое слово будет прочитано проверяющим.

Запросите смету после короткого брифа: вышлем расчёт и предварительный план-график, состав работ зафиксируем в договоре. Цены «от» по разработке самой КД собраны в прайсе.

Утверждённое ТЗ живёт дальше в электронном виде: версия фиксируется, правки идут через реестр изменений, а не через «финальный_вариант_2_испр». Когда по этому заданию стартует разработка КД, изменения самого комплекта пойдут уже по правилам ЕСКД, через извещения; связка двух процедур закладывается в ТЗ заранее.

Пример из практики

Заказчик готовил допуск строительных блок-контейнеров на объект: площадка запросила подтверждение обработки материалов, а внутреннее техзадание существовало в виде одной страницы пожеланий. Запросили этот документ, сопоставили формулировки с требованиями к пожарным характеристикам материалов и с составом КД по ЕСКД, нашли расхождения ещё до передачи разработчику. Подготовили новую редакцию ТЗ: измеримые требования, перечень испытаний, критерии приёмки документации. После согласования выдали финальное задание и чек-лист для контроля подрядчика; комплект прошёл проверку площадки без возврата на доработку, а спор «мы это не заказывали» не состоялся, потому что предмет спора исчез.

Частые сложности и как их решаем

Нет технического описания: формируем его совместно, мы задаём структуру и вопросы, ваш технолог заполняет параметры и процессы. Неясен код классификатора: уточняем через бриф и назначение изделия; при разработке ТУ код по ОКПД2 фиксирует технолог в самом документе. Стейкхолдеры хотят разного: проводим согласование требований, расставляем приоритеты и закрепляем компромисс в критериях приёмки, чтобы спор не переехал на сдачу. Нужна электронная модель: заранее закладываем форматы, уровень детализации и правила обмена, иначе «модель есть, но не открывается» обнаружится в худший момент.

Кому подходит услуга, а кому нет

Сверьте свою ситуацию с таблицей до заявки.

Когда услуга не нужна

Три ситуации, в которых деньги на разработку задания тратить не стоит.

Документация утеряна, но живой образец изделия на руках. Новое проектирование здесь не требуется: комплект восстанавливается обмером и анализом образца, а роль задания играет короткая программа работ. Дешевле заказать восстановление КД методом реверс-инжиниринга.

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

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