Подготовка технического задания по 223 ФЗ

Содержание

Согласно положениям закона 223-ФЗ от 18.07.2011 года, заказчик обязан разработать документацию к закупке и обеспечить информирование участников об условиях исполнения контракта. Жестких требований к перечню бумаг не установлено. Сведения о поставке, оказании услуги или проведении работ юристы рекомендуют отражать в техническом задании.

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

Принципы составления документации

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

1) Индивидуальная разработка

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

2) Детальность описаний

Точность формулировок исключает вероятность возникновения споров и направления жалоб в ФАС РФ. Юристы рекомендуют уделить внимание наиболее острым вопросам. Так, серьезной проблемой стал формальный подход к составлению технических предложений. Участники закупки копируют раздел информационной карты и используют выдержки без изменений.

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

Важно! Метод не применяется при закупке специфических товаров, работ или услуг.

3) Ограничения

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

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

4) План

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

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

В настоящем разделе представлены методические материалы для подготовки к проведению закупки на оказание образовательных услуг по повышению квалификации в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд в соответствии с Федеральным законом от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд».

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

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

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

Согласно письму Минэкономразвития России от 06.05.2016 № ОГ-Д28-6303 для определения и обоснования НМЦК методом анализа рынка возможно использование прайс-листов поставщиков (подрядчиков, исполнителей), в том числе размещенных на официальных сайтах, что является наиболее объективным обоснованием, так как указанная в них информация о ценах направлена на неопределенный круг лиц.

Пример обоснования НМЦК в документации о закупке (федеральные государственные служащие)

Пример обоснования НМЦК в документации о закупке (иные категории)

Правила описания объекта закупки по 223-ФЗ начали действовать с 01.07.2018 (ч. 6.1 ст. 3). Ранее законодатель оставлял заказчику определенную свободу в этом вопросе. Заказчик сам устанавливал правила, а единственной обязанностью было прописать их в положениях о закупках. Теперь регламентирует описание объекта закупки 223-ФЗ.

Как описать объект закупки по 223-ФЗ по новым правилам

Описывая предмет закупки в документации, нужно указать следующее:

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

Предъявляемые условия должны соответствовать техническим регламентам и документам о стандартизации (ГОСТы, СанПиНы). Если заказчик предъявляет иные требования, он должен это обосновать в документации (ч. 10 ст. 4).

Введено ограничение использовать при описании ТРУ:

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

Не допускается устанавливать иные необоснованные требования к ТРУ, которые могут ограничить конкуренцию:

Как использовать товарные знаки при описании продукции

Под товарным знаком, как указано в ст. 1477 ГК РФ, понимается обозначение, которое обеспечивает индивидуализацию товаров. Описание может быть словесным или в виде изображения.

В описании объекта закупки допускается указать товарный знак, если нет другого способа четко прописать требования, в следующих случаях:

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

ВАЖНО! Если в документации и описании объекта указана марка и нет слов «или эквивалент», поставщик должен поставить товар именно указанной марки, поставка эквивалентного товара не допускается.

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

Как составить техническое задание

Техническое задание 223-ФЗ определяет как одну из частей документации о закупке. Оно содержит основные требования к закупаемым ТРУ. Описание должно быть объективным, понятным, непротиворечивым. Не следует включать в одну закупку технологически и функционально не связанные товары, лицензируемые и нелицензируемые услуги (ст. 17 закона от 26.07.2006 № 135-ФЗ).

Образец технического задания по 223-ФЗ должен содержать информацию:

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

Образец технического задания по 223-ФЗ

Скачать

В принципе, существует два типа Технического Задания:

  • документ, которые составляется заказчиком, для проведения тендера по выбору исполнителя на разработку сайта.

Именно его мы и рассмотрим в данной статье

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

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

Для чего нужно грамотное техническое задание и кому оно предназначено?

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

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

Большинство заказчиков думают, что достаточно написать в брифе:

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

или:

Добрый день!
Открываем свой интернет-магазин с поставками из Китая.
Нужен достаточно быстро сделать интернет-магазин мужской и женской одежды.
Ожидаем предложения по сайту со сроками и суммами.
А также пришлите сразу предложение по продвижению.

И последнее (чтобы добить):

Подготовка интернет магазина на платформе 1С — Битрикс малый бизнес.
Отрасль торговля, интернет магазин детской одежды и товаров для малышей до 3 лет.
Хорошие карточки товаров, возможность выбирать по различным характеристикам, выбор показа по 25, 50 и более.
Варианты доставки с калькулятором
Способы оплаты
Удобная корзина

(цитаты дословные, орфография и пунктуация авторские)

Таким заказчикам как раз и призвана помочь эта статья.

Почему нельзя писать такие ТЗ как приведенные выше?

Во-первых: можно соблюсти вышеуказанные требования сделав сайт за 20 000р, а можно сделать за 1 000 0000р и не угадать — какой-то он некрасивый получился, карточка товара нехорошая, корзина вообще неудобная.

Во-вторых: категорически избегайте в ТЗ оценочных характеристик: «красивый, удобный, функциональный» и т. д.! По каким критериям и кто будет определять степень красивости и удобства сайта?!

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

Описание компании — заказчика.

Описывает продукты/услуги компании, целевую аудиторию, конкурентное поле и т. д.

Например так:

  • ООО «Компания» является розничной компанией.
  • Основной вид деятельности компании — розничная торговля периодической печатью и продуктами питания.
  • Приоритетные направления деятельности:
    • Развитие розничной торговой сети в бизнес-центрах;
    • Развитие розничной торговой сети в аэропортах;
  • Компания ведет свою деятельность в Москве, Санкт-Петербурге, Екатеринбурге, Новосибирске, Тюмени, Самаре, Казани, Челябинске, Владивостоке, Уфе, Красноярске и Минеральных водах.

Целевая аудитория сайта (кому предназначен).

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

Примерно так:

  • Целевая аудитория Сайта представлена следующими группами пользователей:
  • Поставщики товаров;
  • Организации, заинтересованные в продвижении товаров и услуг.
  • Физические лица и организации, заинтересованные в открытии розничных торговых точек под брендом «Хорошие Новости» (франчайзи);
  • Партнеры (аэропорты, бизнес-центры);
  • Розничные клиенты;
  • Органы власти РФ;
  • Средства массовой информации (СМИ).

Цель, задача, тип сайта (вытекает из. п.2).

Описывает функциональное назначение.

Например: формирование экспертного имиджа компании, и, как следствие, тип сайта- новостной/информационный ресурс, корпоративный портал.

Или: инструмент продаж и, как следствие, розничный интернет-магазин с корзиной и эквайрингом;

Либо: онлайн каталог для осуществления оптовых продаж оффлайн.

Вот пример из того же (грамотно написанного заказчиком ТЗ):

Назначение Сайта Основным назначением Сайта является создание официального представительства компании Заказчика в сети Интернет. Цель создания Сайта Целью создания Сайта является модернизация существующего сайта www.domen.ru. Целевая аудитория Сайта Целевая аудитория Сайта представлена следующими группами пользователей:

  • Поставщики товаров;
  • Организации, заинтересованные в продвижении товаров и услуг.
  • Физические лица и организации, заинтересованные в открытии розничных торговых точек под брендом «Хорошие Новости» (франчайзи);
  • Партнеры (аэропорты, бизнес-центры);
  • Розничные клиенты;
  • Органы власти РФ;
  • Средства массовой информации (СМИ).

Основные задачи Сайта

Сайт должен обеспечивать реализацию следующих задач.

1) Имиджевая Сайт является «лицом» компании ООО «Компания» в интернет и должен:

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

2) Информационная Сайт должен предоставлять пользователям доступ к информации:

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

Нет необходимости в ТЗ включать бриф на разработку дизайна. Для расчета стоимости проекта достаточно просто указать — потребуется ли разработка дизайна, или заказчик готов предоставить исходники для верстки.

Прототип интерфейса сайта.

Очень важный пункт для понимания проекта как самим заказчиком так и исполнителем!

Описывает разделы сайта, пункты меню/подменю, схему навигации по сайту.

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

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

Например так:

Нам необходимо создать сайт аналогичный www.domen.ru
Необходимо исключить модули: …, …..
Добавить раздел: ….

Если разрабатываемый сайт аналогов не имеет, то придется прототипировать интерфейс примерно так:

4.1. Функциональные возможности сайта.

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

Например:

Сайт должен иметь:

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

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

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

4.2. Проект функционала сайта

В графическом и текстовом виде описывает п. 4.1.

Самый важный и самый объемный пункт ТЗ.

Критическим образом определяет всю дальнейшую работу и взаимоотношения заказчика и подрядчика.

Важно понимать — если функционал и внешний вид какого-либо модуля не описан предельно четко и понятно, он со 100% вероятностью будет реализован не так, как это видит себе заказчик, но так как исполнитель считает «правильно».

Содержит:

  • схемы расположения модулей и информационных блоков на страницах;
  • внешний вид меню/подменю, элементов;

Важно!

В этом пункте необходимо подробно описать как именно выглядит и функционирует модуль.

Например, пишем: блок «новости».

Где этот блок расположен и на каких страницах отображается мы уже указали в п.4 ТЗ (ведь там приложена графическая схемка, да? :-))
Но, оказывается, этого крайне недостаточно!
Сколько новостей будет анонсироваться в модуле? 3–5 может быть 10 последних?
А анонс должен демонстрировать кроме заголовка еще и краткое содержание?
А фото-превью в анонсе будет?
А в самой новости, размещенной в соответствующем разделе, будет демонстрироваться фото высокого качества?

Или: «форма обратной связи».

  • указать количество полей в форме обратной связи (да! Просто написать «форма обратной связи» недостаточно);
  • описать — что именно будет делать форма: формировать лид в CRM, отправлять письмо на почту менеджеру и т. д.
  • описать- будет ли форма проверять валидность вводимой информации: позволит ли в поле «телефон» вбить набор букв, а в поле «e-mail» — набор цифр;

К более сложным элементам и описание необходимо составить гораздо более исчерпывающее.

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

Во-первых: не путать личный кабинет покупателя с личным кабинетом менеджера/администратора.

Во-вторых: описать что именно и кому он отображает в зависимости от уровня доступа/рейтинга пользователя.

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

Блок «товарный каталог».

Для 1С-Битрикс это типовой компонент, описывать функционал нет необходимости (конечно, если вы выбрали иную CMS, то и функционал придется описать).

Однако! Внешний вид каталога, логику и последовательность действий пользователя описать придется подробно:

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

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

  • Функционал разделов и модулей из п.п. 4.1. 4.2. — стандартный.

5.Технические требования

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

Рекомендуем заполнять это траздел только в случае, если проект является в каком-то роде не типовым.

Например:

  • посещаемость планируется несколько тысяч заходов в сутки;
  • товарный каталог представлен несколькими десятками тысяч позиций;

Пример, как писать НЕ НАДО:

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

Сайт должен обеспечивать корректное отображение данных в следующих браузерах:

  • Internet Explorer (версия 5.5 и выше);
  • Opera (версия 7.0 и выше);
  • Mozilla Firefox (версия 1.0 и выше).

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

Требования к системе управления контентом Сайта

Система управления контентом Сайта должна обеспечить администратору сайта возможность выполнения следующих действий:

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

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

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

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

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