Техническое задание на информационную систему по 44-ФЗ — это документ, в котором заказчик описывает функциональные требования к будущему программному продукту. Главная сложность ИТ-закупок в том, что их легко превратить в «заточку» под конкретного поставщика: достаточно упомянуть определённую платформу, архитектуру или набор модулей, которые выпускает только одна компания. Такое техническое задание почти гарантированно приведёт к жалобе в ФАС и ограничению конкуренции. Разберём, как составить описание объекта закупки так, чтобы оно было точным для исполнителя и одновременно нейтральным с точки зрения закона.
Что такое ограничение конкуренции в ИТ-закупке
Ограничение конкуренции — это ситуация, когда требования технического задания искусственно сужают круг участников. Формально закупка конкурентная, но фактически подать заявку может только одна организация или узкий круг связанных компаний.
В ИТ-сфере это проявляется особенно часто, потому что заказчику хочется получить ровно тот продукт, который он уже видел на демонстрации. В результате в техническое задание попадают:
- названия конкретных программных продуктов и вендоров;
- описание уникальной архитектуры или алгоритмов, характерных для одного решения;
- требования к интерфейсу, повторяющие дизайн конкретной системы;
- ссылки на стандарты и регламенты, которым соответствует только один продукт;
- жёсткие требования к опыту, сертификатам и штату, которые выдерживает лишь один участник.
Закон о контрактной системе требует описывать объект закупки объективно, а функциональные, технические и качественные характеристики — так, чтобы они не указывали на конкретного производителя. Если без товарного знака обойтись невозможно, его указывают с оговоркой «или эквивалент». Но для информационных систем этот приём работает плохо: эквивалентность ПО доказать сложнее, чем эквивалентность канцелярской бумаги.
Функциональные требования как основа технического задания
Ключ к безопасному техническому заданию — описывать не продукт, а функции и результат. Заказчику важно, что система должна делать, а не как она устроена внутри.
Функциональные требования формулируют через задачи пользователя:
- какие данные система принимает и в каком виде;
- какие операции выполняет с этими данными;
- какие отчёты и выгрузки формирует;
- с какими внешними системами интегрируется и по каким протоколам;
- какие роли пользователей и права доступа поддерживает;
- какие требования к нагрузке, времени отклика и доступности.
Такой подход оставляет поставщику свободу в выборе технологий, но не даёт размытого результата. Заказчик получает работающую систему, а не абстрактное «современное решение».
Пример нейтральной и ограничивающей формулировки
Ограничивает конкуренцию: «Система должна быть построена на платформе 1С:Предприятие 8.3 с использованием модуля X и подсистемы Y».
Нейтральная формулировка: «Система должна обеспечивать ведение учёта договоров, формирование печатных форм по заданным шаблонам, выгрузку данных в формате XML по согласованной схеме и интеграцию с бухгалтерским ПО заказчика посредством открытого API».
Во втором случае требование проверяемо, но не диктует конкретный стек технологий.
Пошаговый порядок подготовки технического задания
- Опишите бизнес-задачу. Сформулируйте, какую проблему решает система и какой измеримый результат нужен заказчику.
- Соберите требования от пользователей. Опросите будущих операторов системы, зафиксируйте сценарии работы.
- Переведите сценарии в функциональные требования. Каждый сценарий — это набор операций, входных и выходных данных.
- Проверьте требования на нейтральность. Уберите названия продуктов, вендоров, уникальных архитектур и «фирменных» терминов.
- Определите требования к интеграции и данным. Опишите форматы обмена, протоколы и состав передаваемых сведений.
- Установите измеримые критерии приёмки. Время отклика, объём обрабатываемых записей, перечень отчётов, порядок тестирования.
- Проверьте обоснованность требований к участнику. Опыт, лицензии и специалисты должны быть связаны с предметом закупки, а не отсекать конкурентов.
- Проведите внутреннюю экспертизу. Покажите проект технического задания юристу и специалистам, которые не участвовали в разработке.
Отдельно проверьте, нет ли в тексте скрытых маркеров: аббревиатур внутренних систем, названий модулей, ссылок на закрытую документацию. Именно такие детали чаще всего становятся основанием для жалобы.
Практический пример: закупка системы электронного документооборота
Заказчику нужна система электронного документооборота. Первоначально техническое задание содержало требование «интерфейс должен повторять структуру папок и карточек, реализованную в системе N», а также перечень из двадцати специфических отчётов с названиями, совпадающими с отчётами одного вендора.
После экспертизы требования переписали:
- вместо структуры интерфейса описали сценарии согласования документов и роли участников;
- вместо фиксированных отчётов — перечень показателей, которые система должна выводить, и требования к выгрузке в табличном формате;
- вместо названия платформы — требования к поддержке открытых форматов, интеграции по API и работе в браузере без установки дополнительных компонентов.
В результате на закупку вышли несколько участников, а заказчик получил систему, которая закрывает те же задачи. Это типичный пример того, как смещение фокуса с продукта на функцию снижает риск ограничения конкуренции.
Распространённые ошибки
Указание конкретного программного продукта
Прямое упоминание вендора или названия системы — самое очевидное нарушение. Даже если заказчик уверен, что продукт уникален, требование нужно переформулировать через функции.
Скрытые маркеры «под своего» поставщика
Иногда название продукта не пишут, но оставляют уникальные сочетания требований: определённый набор модулей, специфическую последовательность экранов, нестандартный формат отчёта. Формально это не товарный знак, но фактически — то же ограничение.
Избыточные требования к участнику
Требования к опыту, сертификатам и штату должны быть соразмерны предмету закупки. Если для внедрения небольшой системы требуют десять сертифицированных специалистов редкого профиля, это повод для жалобы.
Размытые критерии приёмки
Формулировки «удобный интерфейс», «высокая производительность», «современная архитектура» невозможно проверить. Они создают почву для споров и одновременно позволяют необоснованно отклонять заявки.
Отсутствие обоснования начальной цены
Для ИТ-закупок метод сопоставимых рыночных цен требует корректных коммерческих предложений. Если они собраны у аффилированных лиц или не соответствуют техническому заданию, расчёт начальной максимальной цены контракта легко оспорить.
Как снизить риски
Проводите технологическую и юридическую экспертизу технического задания до публикации извещения. Привлекайте к проверке специалистов, не заинтересованных в конкретном поставщике. Фиксируйте обоснование каждого требования — это поможет при разборе жалобы. Используйте функциональные и измеримые формулировки вместо описания продуктов. Следите за изменениями законодательства и практикой ФАС: подходы к ИТ-закупкам регулярно уточняются.
Для системной подготовки специалистов по описанию объекта закупки и разбору типичных нарушений подойдёт программа по жалобам и практике ФАС: в ней рассматриваются причины жалоб, проверки и ответственность заказчика. Освоить работу в ЕИС на практике, включая размещение извещений и документации, помогает практикум на тренажёре ЕИС.
Итог
Техническое задание на информационную систему по 44-ФЗ должно описывать функции, данные и результат, а не конкретный продукт. Нейтральные формулировки, измеримые критерии приёмки и обоснованные требования к участникам снижают риск жалоб и расширяют круг поставщиков. Проверка документа независимым специалистом и опора на актуальную практику ФАС помогают избежать ошибок ещё до публикации извещения.
