Контакты

Техническое задание на закупку по. Наболевшее про шаблон технического задания для тендеров

Нормативные документы и правовые аспекты

Наболевшее про шаблон технического задания для тендеров

Люция Васильева 29 января 2015 г. 14:18

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

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

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

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

Теперь рассмотрим действия участника закупки (поставщика). Если я как исполнитель заинтересован в получении контракта с клиентом, то я подготовлю подробную пояснительную записку - заявку на участие в тендере, изучу и прокомментирую все пункты технического задания. Даже если мой продукт сегодня «не умеет что-то делать», то у меня будет время «его научить», либо после подписания контракта будет время понять потребность клиента и предложить альтернативный вариант. Конечно, всё в рамках законодательства.

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

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

Запрос котировок и аукцион — это способы закупки по наименьшей стоимости. Поэтому техническое задание должно быть ёмким:

● включать подробное описание того, что будет поставляться, настраиваться, устанавливаться или модифицироваться;

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

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

Конкурс — это способ закупки для определения поставщика с лучшими условиями исполнения контракта. Здесь применимо все, что написано выше, но при этом есть и дополнительный «рычаг», про который поставщики часто забывают. Речь идет о критериях оценки заявок.

Методика оценки заявок подробно изложена в Постановлении Правительства РФ от 28.11.2013 №1085 «Об утверждении Правил оценки заявок,..» . Выделяйте в критерии определения победителя важные для клиента сильные стороны исполнителя.

Общие положения технического задания

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

Цели проекта

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

Функциональные требования


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

Функциональные требование – это те варианты исполнения, которые вы хотите видеть у себя.

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

Сроки

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

Отчетность

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

Ответственность

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

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

Как правильно подготовить техническое задание к тендеру по информационной безопасности

При подготовке ТЗ для тендера желательно руководствоваться требованиями стандарта ГОСТ 34.602-89 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы». Документ поможет выстроить четкую структуру технического задания, определить разделы, которые будут заполняться необходимыми требованиями.

Рассмотрим, на что нужно обратить внимание при заполнении документа.

Техническое задание на тендер, образец (примерная структура)

Общие сведения

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

Основание проведения работ. Цели создания системы

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

Зачастую основанием для создания системы выступают требования законодательства. В таком случае необходимо перечислить нормативные документы, в соответствии с которыми система должна быть создана. Например, требования 152-ФЗ «О персональных данных».

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

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

Общая характеристика информационных систем

Этот раздел посвящен описанию существующей инфраструктуры заказчика. Лучше заполнить этот раздел максимально подробно.

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

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

Требования к системе защиты информации

В данном разделе указывают требования к системе защиты, которым она должна соответствовать. Раздел можно условно поделить на два подраздела — общие требования к системе и требования к функциям, выполняемым системой.

Общие требования к системе

В подразделе «Общие требования к системе» указывают:

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

Требования к функциям, выполняемым системой

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

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

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

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

В данном подразделе к программным средствам системы защиты следует указать:

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

Требования к техническим средствам

В подразделе указываются:

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

Состав и содержание работ

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

Порядок контроля и приемки системы

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

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

Требования к исполнителю

Один из завершающих разделов — «Требования к исполнителю».

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

Требования по гарантийному сопровождению

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

Требования к документированию

Заказчик указывает требования к перечню подлежащих разработке исполнителем комплектов и видов документов, требования по предоставлению документов.

Например, документы должны быть предоставлены в печатном виде на бумажном носителе и в электронном виде, записанные на носитель CD-Rom, DVD-Rom.

Какие ошибки чаще всего встречаются при подготовке ТЗ

Заказчик не знает, на основании какого документа подготовить техническое задание.

За основу можно взять ГОСТ 34.602-89 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы» и наполнить документ необходимым материалом.

В разных местах одного и того же технического задания идут противоречия.

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

Сжатые сроки выполнения технического задания.

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

Мы рекомендуем заказчикам при подготовке ТЗ обращать больше внимания на раздел «Состав и содержание работ». В этом пункте можно детализировать работы и разбить их на отдельные этапы, провести анализ сроков выполнения каждого из этапов. Это позволит получить более объективную картину по срокам выполнения всего ТЗ.

В техническом задании прописаны требования к несуществующим продуктам.

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

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

При подготовке ТЗ на работы / услуги часто встречаются варианты, когда не зафиксирован четкий перечень работ / услуг, не определены результаты оказания работ / услуг.

В таких случаях вероятны конфликты между заказчиком и исполнителем, поскольку оказанные исполнителем услуги или работы не будут соответствовать ожиданиям заказчика. Чтобы этого не произошло, заказчику при подготовке ТЗ необходимо больше внимания уделять разделам «Основание проведения работ. Цели создания системы» и «Состав и содержание работ». Практика показывает, что лучше разбить работы на отдельные этапы. Описать требования к каждому из этапов, зафиксировать сроки выполнения и результаты работ по каждому из этапов. Эти действия позволят улучшить контроль за выполнением работ или оказанием услуг.

Вывод

Грамотно составленное техническое задание будет полезно одновременно и исполнителю и заказчику. Исполнителю оно позволит адекватно оценить масштаб работ без дополнительных запросов и разъяснений, а также предложить наиболее подходящее заказчику техническое решение. Заказчику — позволит получить качественно выполненную работу по созданию системы защиты, максимально соответствующую его ожиданиям.

Станислав Шиляев , руководитель проектов по информационной безопасности компании «СКБ Контур»

Понравилась статья? Поделитесь ей