Техническое задание гост

Системы видеонаблюдения сегодня устанавливаются во многих учреждениях. Рассмотрим требования к описанию такого объекта закупки и приведем образец технического задания на видеонаблюдение.

Структура технического задания

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

1. Цель.

Для системы видеонаблюдения изложите ее назначение (какие задачи она должна решать).

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

2. Зоны контроля.

Составляется детализированный план объекта, на котором планируется установить видеонаблюдение, с указанием условий окружающей среды (температура, влажность, освещение, и др.), а также уточняются требования к плотности пикселей в зоне обзора.

3. Необходимое оборудование.

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

4. Проектная документация.

Предоставить текстовые и графические материалы, определяющие архитектурные, функционально-технологические, конструктивные и инженерные решения. Как минимум необходимо составить план территории. А если планируется проектирование — подробное описание объекта.

5. Законодательное регулирование.

Составляя описание, необходимо использовать только показатели, единицы измерения и термины, которые предусмотрены техрегламентами и документами национальных стандартов РФ. Заказчик может воспользоваться:

  • ГОСТ Р 51558-2014 «Средства охранные телевизионные. Классификация. Методы испытаний»;
  • ГОСТ Р 53246-2008 «Информационные технологии. Системы кабельные структурированные. Общие требования»;
  • ГОСТ 34.201-89 «Информационная технология. Комплекс стандартов на автоматизированные системы»;
  • ГОСТ 31565-2012 «Кабельные изделия»;
  • ГОСТ Р 50776-95 «Часть 1. Раздел 4. Руководство по проектированию, монтажу и обслуживанию на конкретную систему видеонаблюдения»;
  • Федеральный закон 123-ФЗ. Техрегламент о требованиях пожарной безопасности;
  • СП 134.13330.2012 «Системы электросвязи зданий и сооружений. Основные положения проектирования».

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

Алгоритм составления технического задания

Общие требования к описательной части ТЗ и алгоритму его составления приведены в статьях: Описание объекта закупки по 44-ФЗ, Как написать ТЗ для тендера.

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

План составления технического задания следующий:

Шаг 1. Наименование объекта и объема закупаемых работ.

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

Шаг 3. Дата завершения работ.

Шаг 4. Гарантия, гарантийное обслуживание.

Шаг 5. Место выполнения работ.

Шаг 6. Необходимость осуществления наладки, монтажа.

Образец технического задания на установку видеонаблюдения

Скачать

Приложение 2. Пример составления технического задания на разработку программного продукта

⇐ Предыдущая17181920212223242526Следующая ⇒

МИНИСТЕРСТВО НАУКИ И ОБРАЗОВАНИЯ

РОССИЙСКОЙ ФЕДЕРАЦИИ

ГОУ ВПО «АДЫГЕЙСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ»

ФИЗИЧЕСКИЙ ФАКУЛЬТЕТ

КАФЕДРА АСОИУ

ТЕХНИЧЕСКОЕ ЗАДАНИЕ НА СОЗДАНИЕ ПРОГРАММНОГО

ПРОДУКТА

 

Содержание

 

ВВЕДЕНИЕ…………………………………………….…………………………. … 3

1. ОСНОВАНИЕ ДЛЯ РАЗРАБОТКИ……………………………………….. ……4

1.1. Документ, на основании которого ведётся разработка……………………….4

1.2.

Организация, утвердившая основание разработки, и дата его утверждения4

1.3. Наименование темы разработки…………….………………………………….4

2. НАЗНАЧЕНИЕ РАЗРАБОТКИ……………….…………………………………..5

2.1 Критерии эффективности и качества программы…….………………………..5

2.2 Цели разработки программы…………………………….………………………5

3. ТРЕБОВАНИЯ К ПРОГРАММЕ…………………………….……………………6

3.1 Требования к функциональным характеристикам………….………………….6

3.1.1 Состав выполняемых функций………………………………..……………….6

3.1.2 Организация входных и выходных данных…………………….…………….6

3.1.3 Временные характеристики и размер занимаемой памяти……..……………6

3.2 Требования к надежности…………………………………………….……….…6

3.2.1 Требования к надежному функционированию……………………….………6

3.2.2 Контроль входной и выходной информации……………………………..…..7

3.2.3 Время восстановления после отказа……………………………………….….7

3.3 Условия эксплуатации……………………………………………………………7

3.4 Требования к составу и параметрам технических средств……………………7

3.5 Требования к языкам программирования……………………………………….8

3.6 Требования к программным средствам, используемым программой…………8

3.7 Требования к программной документации……………………………………..8

4. ТЕХНИКО-ЭКОНОМИЧЕСКИЕ ПОКАЗАТЕЛИ………………………… ….. 9

5. СТАДИИ И ЭТАПЫ РАЗРАБОТКИ………………………………………………9

6. ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ……………………………………………9

6.1 Виды испытаний…………………………………………………………………..9

6.2 Общие требования к приёмке…………………………………………………..10

7. ЭТАПЫ ВНЕДРЕНИЯ……………………………………………………………10

 

ВВЕДЕНИЕ

 

Полное наименование программной разработки: "Программа К", в дальнейшем именуемая как "программа". Краткое название программы – «ПК».

На данный момент аналогичных программных продуктов не существует.

Разрабатываемая программа применяется на любом предприятии, где имеется рабочий персонал.

Разработчик данного программного продукта — студент группы 4А1 Иванов А.В. в дальнейшем именуемый как "разработчик ".

Заказчик программного продукта – ОАО «РТС», в лице директора А.М. Гутенко.

 

1 ОСНОВАНИЕ ДЛЯ РАЗРАБОТКИ

 

1.1 Документ, на основании которого ведётся разработка

Работа ведётся на основании задания по дисциплине «Теоретические основы автоматизированного управления»

1.2 Организация, утвердившая этот документ, и дата его утверждения

Задание утверждено и выдано начальником технического отдела ОАО «РТС» Козаковым А.В.

_______________________________Козаков А.В.

1.3 Наименование темы разработки

Наименование темы разработки – «Учёт рабочего времени».

 

2 НАЗНАЧЕНИЕ РАЗРАБОТКИ

 

Данная разработка является семестровой работой по дисциплине «Теоретические основы автоматизированного управления»

2.1 Критерии эффективности и качества программы

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

Соответствие текущему состоянию на рынке ПО данного профиля. В отличие от дорогих и сложных программ «ПК» идеально подходит для представителей бизнеса, так как содержит все, что им необходимо, но не перегружена бесполезными и ненужными возможностями. Технология создания программы в визуальных средах программирования делает ее интерфейс универсальным и совместимым с операционными системами Windows 95/98/2000/XP.

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

 

2.2 Цели разработки программы

Создание данной программы преследует ряд технико-экономических целей:

— Создание программного продукта, необходимого для учёта рабочего времени.

— Создание дешевой альтернативы существующим в настоящее время дорогим программам.

— Создание интуитивно понятной программы с удобным и универсальным Windows.

 

ТРЕБОВАНИЯ К ПРОГРАММЕ

 

 


⇐ Предыдущая17181920212223242526Следующая ⇒


Дата добавления: 2016-10-27; просмотров: 1695 | Нарушение авторских прав


Похожая информация:


Поиск на сайте:


ГОСТ 19.201-78 Техническое задание, требования к содержанию и оформлению

ГОСТ 19.201-78 Техническое задание, требования к содержанию и оформлению

УДК 002:651.7/.78:006.354

Группа Т55

 

Г О С У Д А Р С Т В Е Н Н Ы Й   С Т А Н Д А Р Т   С О Ю З А   С С Р


Единая система программной документации

ГОСТ 19.201-78

(СТ СЭВ 1627-79)

 

ТЕХНИЧЕСКОЕ ЗАДАНИЕ.
ТРЕБОВАНИЯ К СОДЕРЖАНИЮ И ОФОРМЛЕНИЮ

 

United system for program documentation.
Technical specification for development. Requirements to contents and form of presentation


Постановлением Государственного комитета СССР по стандартам от 18 декабря 1978 г. № 3351 срок введения установлен

с 01.01. 1980 г.

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

Стандарт полностью соответствует СТ СЭВ 1627-79.

1. ОБЩИЕ ПОЛОЖЕНИЯ

1.1. Техническое задание оформляют в соответствии с ГОСТ 19.106-78 на листах формата 11 и 12 по ГОСТ 2.301-68, как правило, без заполнения полей листа. Номера листов (страниц) проставляются в верхней части листа над текстом.

1.2. Лист утверждения и титульный лист оформляют в соответствии с ГОСТ 19.104-78.

Информационную часть (аннотацию и содержание), лист регистрации изменений допускается в документ не включать.

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

1.4. Техническое задание должно содержать следующие разделы:

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

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

(Измененная редакция, Изм. № 1)

2. СОДЕРЖАНИЕ РАЗДЕЛОВ

2.1. В разделе «Введение» указывают наименование, краткую характеристику области применения программы или программного изделия и объекта, в котором используют программу или программное изделие.

(Измененная редакция, Изм.

№ 1)

2.2. В разделе «Основания для разработки» должны быть указаны:

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

(Измененная редакция, Изм. № 1)

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

2.4. Раздел «Требования к программе или программному изделию» должен содержать следующие подразделы:

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

(Измененная редакция, Изм. № 1)

2.4.1.

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

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

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

2.4.4. В подразделе «Требования к составу и параметрам технических средств» указывают необходимый состав технических средств с указанием их основных технических характеристик.

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

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

(Измененная редакция, Изм. № 1)

2.4.6. В подразделе «Требования к маркировке и упаковке» в общем случае указывают требования к маркировке программного изделия, варианты и способы упаковки.

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

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

(Введен дополнительно, Изм. № 1).

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

2.6. В разделе «Стадии и этапы разработки» устанавливают необходимые стадии разработки, этапы и содержание работ (перечень программных документов, которые должны быть разработаны, согласованы и утверждены), а также, как правило, сроки разработки и определяют исполнителей.

2.7. В разделе «Порядок контроля и приемки» должны быть указаны виды испытаний и общие требования к приемке работы.

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

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

Переиздание (Ноябрь 1987 г.) с Изменением № 1, утвержденным в июле 1981 г (ИУС 7-81)

В закупочной документации аукциона на заказ в котором используются или поставляются товары (физически осязаемые вещи) должны быть явно приложены требования заказчика к этим товарам.
Смета, дефектная ведомость, обоснование НМЦ, и даже техническое задание не являются требованиями к качеству товаров по умолчанию, если об этом прямо не заявлено в инструкции по заполнению заявки.
Гипотетически заказчик может и не предъявлять никаких требований к товарам, но тогда ему ожидаемо поставят самое худшее из возможных.
При наличии требований участники пишут свои предложения из которых и состоит первая часть аукционной заявки.
Заказчик проверяет предложения участников на их соответствие своим требованиям до аукциона и отклоняет не прошедших такую проверку. Первые части заявок по умолчанию анонимны.

Также эта статья посвящена написанию технических заданий(ТЗ) в целом.
Это действительно сложная тема, требующая постоянной борьбы с ленью человеческого мозга.
Начнём с мыслей о том, как люди ходят в магазин за йогуртом. Ленивый мозг выбирает наиболее «красивый» , тот на котором нарисованы сочные фрукты, чьё название приятно ласкает слух, ассоциируется со скандинавией, или очень часто повторялось по телевизору…
Большинство людей производят эмоциональную (то есть очень глупую) оценку товара.
И лишь немногие «зануды», либо молодые мамы, берут этот йогурт, переворачивают, и вместо сочной картинки начинают читать его состав. Какая жирность? Нет ли там крахмала? Растительных жиров (пальмового масла)?

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

Грамотный (занесённый в красную книгу) заказчик выявляет критически важные для него потребительские свойства товара (не обязательно все) и указывает их худшие допустимые значения. Если его волнует только жирность йогурта, то он пишет «не более 4%». Если мы имеем дело с гениальным закупщиком, то он ещё и напишет «не должен содержать крахмал и растительные жиры».
И уж конечно этот редкий представитель человеческого рода никогда не указывает на название, бренд, фирму (юридически: товарный знак) этого йогурта (исключения ниже). Одна из основных задач закупщика — поддерживать конкуренцию: равные возможности для разных поставщиков.

Ленивый мозг: «Окей, ребята, я всё понял! Мне нельзя указывать товарный знак, нужно писать тех показатели. Сейчас я скачаю из интернета спецификацию нужного мне товара, скопирую её полностью (кроме бренда) в тех.задание и буду отдыхать. Правильно же?».

Нет, неправильно.
Давайте рассмотрим товар холодильник. В его спецификации указаны (например) такие уникальные параметры как габариты (размеры) в миллиметрах. Если вы бездумно скопировали эти размеры в ТЗ(техзадание), то участники теперь обязаны вам поставить именно такой холодильник с точностью до миллиметра. И такое ТЗ ограничивает конкуренцию, нарушает закон.
Да, можно взять показатели из данных понравившегося товара, но…
Очень глупо(и заказчик не обязан) перечислять абсолютно все показатели. Если речь идёт об обычном бытовом двухкамерном холодильнике то какая разница сколько его высота в миллиметрах?
*Если у вас ниша под холодильник ограниченных размеров, то да, вы осознанно ограничиваете размеры в ТЗ.
Очень полезно сопроводить данные (часть данных) расширительными формулировками («более-менее» ,»от-до» итп), что бы участники могли представить любой товар, обладающий минимально допустимыми или более лучшими потребительскими характеристиками.

Ленивый мозг: «Что-то я совсем устал! Давайте я просто побольше напишу разной юридической воды типа:
«должно соответствовать требованиям законодательства, ГОСТ, СанПин, СНИП…», тогда всё будет выглядеть ну очень солидно и по-государственному, а я не буду ковыряться в этих нудных показателях, а лучше пойду отдохну!».

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

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

Ленивый мозг: Ну а как же легендарное «должно соответствовать ГОСТ»?
Все существующие товары в РФ должны соответствовать ГОСТ без «ценных указаний» контрактных управляющих.
«Требования» «соблюдать гост» так же юридически «значимы», как требования соблюдать Уголовный Кодекс, написанные дворником на заборе, то есть являются в лучшем случае напоминанием, а на самом деле — пустозвонством, имитацией работы.

Лирическое отступление: У некоторых производителей товаров слово «гост» используется в товарных знаках и даже рекламе. Предполагается, что люди купят сосиски «гост», думая, что они какие-то особо-качественные, а те, которые не называются «гост» — видимо наоборот.
Масштаб этого заблуждения сложно переоценить:
ГОСТ это минимально допустимые (то есть самые плохие) потребительские характеристики которые только можно производить и продавать в стране, и этому минимуму (например содержанию мяса) обязаны соответствовать все сосиски.
Немалое количество отвратного по качеству ***на, поставляемого, например, в армию, тюрьмы итп вполне соответствует ГОСТ… второму сорту*.
Таким образом, гордое заявление производителей о том, что они соответствуют ГОСТ, имеет такую же рекламную ценность, как если бы я (как юрист) хвалился соблюдением Уголовного Кодекса, то есть тем, что я не убиваю бабушек топором.

*Важно: если ГОСТ предусматривает марки или сорта, заказчику нужно указать (например)»сорт высший» или «не ниже первого». То есть разобраться в товаре и принять решение: хочет ли он качественнее или дешевле.

Трусливый мозг:«Но ведь все копируют эту бурду про госты! Как же я смогу иначе?».
Да, быть не таким как все критически тяжело. Можно хитрить: Соберите все эти параграфы из серии «должно соответствовать …» в отдельный документ и назовите его «Напоминание о существующих НПА», потому что вы не можете включать как лампочку по своему желанию ни ГОСТы, ни санпины, ни УК. Можете только напоминать об их существовании.

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

Согласно закону в аукционной документации должна быть:

Инструкция по заполнению заявки

Практика «применения» этого пункта — ещё одна иллюстрация тяжелейшего провала в (анти-)юридическом сознании целой отрасли. Вместо осознанных инструкций: «… в таких-то параметрах выбирать участнику»,
в 99% госзаказов мы найдём абсурдное :
«Не знаю что писать, поэтому скопирую в инструкцию статьи закона, ведь все так делают».
Узнаёте? Привет, ленивый мозг. Я даже как-то видел закупку куда приложили 44-фз целиком.
Точно так же как и с «гостами»:
Закон уже опубликован и должен быть соблюден без его копирования куда-то ещё.
И точно так же как и с «гостами»:
Если закон предусматривает выбор из нескольких пунктов (опций), то этот выбор должен быть сделан и прямо указан.
Это работа закупщика и важнейший юридический принцип: не копипастить то, что уже определено за вас, создавая видимость большой, важной и очень государственной работы,
а принимать осознанные решения в отведённых рамках и транслировать эти решения.
В большинстве простых случаев инструкция может и должна состоять из одной фразы:
«Предложенный участником товар должен быть указан однозначно и являться равным или лучшим по всем требуемым показателям.»
В особых ситуациях в инструкции может быть предложен выбор нескольких значений из заданных диапазонов или перечней:
«Перечисление показателей через запятую означает, что участник может выбрать один или несколько показателей из списка.

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

Затребовать конкретизацию показателей заказчик имеет право в любой закупке, но только в аукционе он будет проверять предложение по ним до самих торгов:
В течении трёх дней после ОПЗ заказчик рассматривает первые части, и в случае несоответствия требованиям закона и заказчика такие заявки не допускаются к участию в аукционе ( обеспечение заявки разблокируется).
Комиссия заказчика якобы голосует по соответствию каждой (первой части) заявки. На практике никаких голосований нет, решение принимает ключевое лицо заказчика (контрактный управляющий).
Отклонение может быть обжаловано, но на аукцион отстранённый участник скорее всего не успеет, возможно итоги аукциона будут отменены ФАС или торги будут продолжены с включением незаконно отстранённых.

показатель Заказчику понравился товар: Заказчик пишет в требованиях участник пишет в предложении
1. Товарный знак Samsung * товарный знак Ariston
страна происхождения — РФ

1. Прямое упоминание товарного знака (производителя, бренда, фирмы) разрешено*** заказчикам для закупок услуг/работ с использованием этого товара.
«Покраска стен краской TIKKURILLA или эквивалент»
Но подобное указание никоим образом не снимает обязанностей описывать этот товар в показателях, то есть указывать, чем же именно хороша эта краска (в цифрах)и каким минимально допустимым её свойствам должны соответствовать её эквиваленты (аналоги, конкуренты).
Упоминание товарного знака запрещено для прямой поставки товаров, «закупка краски водоэмульсионной», «закупка холодильника».
***Кроме приведённых ниже исключений заказчику очень хорошо бы завести привычку никогда не указывать брендов в ТЗ, а сосредоточиться на разборе их технических характеристик.
Исключения (там где можно и нужно указывать «фирму»):
— запасные части или расходные материалы, совместимость которых обусловлена документацией уже используемых заказчиком изделий (картриджи для орг.техники и зап.части для авто являются уникальными в этом смысле видами закупок, т.к. в них законно требовать один единственный бренд-оригинал);
— если не имеется другого способа обеспечить точное описание характеристик (ага, та самая виолончель Amati за 2 млрд. долларов)) Кроме шуточек, звучание уникальных инструментов действительно нельзя измерить в цифре, поэтому можно писать «Страдивари».

показатель Заказчику понравился товар: Заказчик пишет в требованиях участник пишет в согласии
1. Товарный знак Samsung ничего не пишет товарный знак Ariston
страна происхождения — РФ
2. объём 200л не менее 200л 245 литров
3. количество камер 2 2 2
4. класс энергопотребления  А не ниже А А
5. кол-во рабочих циклов  более 20 000 более 20 000 более 20 000
6. температурный режим  от -10 до +5 не хуже чем от -10 до +5  от -15 до +8

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

3. Если заказчику не нужен холодильник с более чем двумя камерами, то и не нужно расширять этот показатель.

4. Если детально разобраться в показателе, то мы узнаем что существуют классы «А+», «А super-eco» итп

5.

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

Упаковка (фасовка) товара — это тоже качественная характеристика, она также может быть затребована. Пример «молоко». Может быть фасовано в пакеты, а может доставляться в бидонах. С точки зрения участника молоко в пакетах во-первых: дороже, а во-вторых: не у всех производителей есть фасовочные линии, а значит это что?
Бодрый мозг: «Ограничение конкуренции!»
Правильно. Но с точки зрения заказчика его поварам неудобно работать с бидонами, а ещё в бидонах хуже хранится итд итп…
Юридически однозначного решения здесь нет. Как и нет повода для войны и ненависти. Если участник решит обжаловать требование к упаковке молока ,то только местное УФАС решит можно так или нельзя в этом конкретном случае.

клише

шаблон

Альтернативные описания

• избитое выражение, шаблонная фраза

• избитое, шаблонное выражение

• иллюстрацион. печатная форма высокой печати

• печатная форма с рельефным рисунком

• печатная форма для оттиска с иллюстрацией

• рельефное изображение на твердом материале для полиграфического воспроизведения

• речевой стереотип

• средство размножения (типографское)

• стереотипное выражение, шаблонная фраза

• шаблонная фраза, ходячее выражение

• ходячее, избитое выражение, избитая фраза

• факсимиле

• речевой штамп

• стандартная, примитивная или подражательная форма изображения

• как по-французски «делать макет из глины»?

• что изготовляют способом цинкографии?

• что типограф травит в кювете?

• французский «шаблон»

• иллюстрационная печатная форма высокой печати

• шаблонная фраза, выражение

• заученная фраза

• фраза, ставшая шаблоном

• избитое выражение

• фраза-стереотип

• оттиск

• типографский оттиск

• печатная форма

• шаблонная фраза

• печатный шаблон

• ходячее выражение

• продукт цинкографии

• «шаблон» у француза

• шаблонное выражение

• ходячая фраза

• опостылевший штамп

• застывшая тема

• печатная форма высокой печати

• застывшая форма

• расхожий речевой оборот, штамп

• стереотипное выражение, шаблон

• словесный шаблон

• штамп

• фраза, затертая до дыр

• штамп, набивший оскомину

• ходячий штамп

• штамп литератора

• «штампованный» ответ

• стереотипное выражение

• Шаблонная фраза, ходячее выражение, речевой штамп

• Полиграфическая печатная форма с рельефным рисунком

• Печатная фоpма с pельефным pисунком

• Иллюстрационная печатная форма с рельефным рисунком

• Расхожий речевой оборот, штамп

Добавить комментарий

Закрыть меню