Как можно исправить ошибки в техзадании на закупку

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

• На стадии подачи заявок

Стадия подачи заявок

На этом этапе у заказчика есть следующие опции:

• внесение изменений в документацию;
• отмена закупки.

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

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

При изменении документации заказчик принимает решение, вносит изменения в извещение и в течение одного дня загружает файл с корректировками через ЕИС.

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

• не менее 15 дней для электронного аукциона;
• не менее 7 дней для электронного аукциона с НМЦК менее 300 млн руб. или НМЦК до 2 млрд руб. в сфере строительства;
• не менее 10 рабочих дней для открытого конкурса в электронной форме;
• не менее 5 рабочих дней для запроса котировок в электронной форме.

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

Бывает и так, что ТЗ надо менять по причинам, которые от заказчика не зависят. Например, если с момента, как было размещено извещение, товар был включен в КТРУ, а в техзадании указано, что его там нет.

В любом случае нельзя вносить изменения, если:

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

В таком случае можно отменить закупку (конкурс, аукцион или запрос котировок). Извещение об отмене размещается через ЕИС. Отменить можно не позднее, чем за 5 дней до даты окончания срока подачи заявок, если это конкурс или аукцион, и 2 дня – если это запрос котировок. Отменить запрос предложений нельзя.

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

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

Стадия рассмотрения заявок

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

Если ошибка в документации, техническом задании все же есть, возможно:

Никто просто не подаст заявок и торги не состоятся. Это благоприятный сценарий, так как он позволит исправить ошибки.

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

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

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

Напомним, что существенными условиями контракта считаются его предмет, а также те условия, которые таковыми признаны законом и самим контрактом. В случае с госзакупками – это почти все его возможные условия, в том числе цена, срок, количество товара или объем работ.
Условия контракта должны соответствовать тому, что написано в документации и техническом задании. Если в ТЗ были неточно указаны объем работ, количество товаров, сроки выполнения или поставки, то изменить ситуацию на стадии, когда контракт уже заключен, тоже возможно. Но далеко не всегда.

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

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

цены контракта и объема работ. Но не более, чем на 10% (исключение – контракты, касающиеся строительства и объектов культурного наследия). Есть и другие основания для изменения цены, но они вряд ли они будут связаны с ошибками технического задания. При этом перечень товаров или работ должен остаться прежним – дополнять его либо исключать какие-либо позиции нельзя;

срока контракта. Срок можно изменить только в отдельных видах контрактов (заключенных с единственным поставщиком, в сфере строительства).

В 2020 году из-за распространения коронавируса в Закон о госзакупках были внесены изменения, которые позволили более гибко регулировать изменение контракта (ч. 65 ст. 112 Закона о госзакупках). До конца 2020 года, если из-за распространения коронавируса (или при других обстоятельствах непреодолимой силы) стало невозможно исполнить контракт, то срок исполнения контракта или его цену изменить можно, но нужно решение органа исполнительной власти соответствующего уровня. Для того, чтобы изменить условия заключенного контракта заказчик и исполнитель (поставщик) заключают дополнительное соглашение.

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

Если статья была вам полезна, пожалуйста, оцените ее по «звездной» шкале ниже, где 5 звезд — очень полезна.

Мы хотим, чтобы вы читали только интересные материалы, и будем благодарны за обратную связь!

Как составить ТЗ: подробная инструкция по созданию технического задания

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

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

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

Техническое задание не менее значимо, чем юридический акт, в деле закрепления прав и обязанностей сторон — заказчика и исполнителя.

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

Когда каждая мелочь регламентирована, всё на своих местах, все при своих полномочиях и обязанностях, остаётся мало пространства для нечестного манёвра и недопонимания. Идеально, когда его вообще не остаётся.

Более того, конкретное и целостное техническое задание — это первый шаг к качественному результату. Чтобы продукт работал чётко, без сбоев, да и просто безопасно — это тоже периодически стоит на повестке — все его элементы должны быть продуманы. Тщательно и скрупулезно.

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

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

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

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

Во многих вакансиях на позицию системного аналитика или технического писателя можно встретить требование: знание ГОСТ 19 и ГОСТ 34. Что это такое?

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

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

Не пугайтесь, но ГОСТ 19 введён в 1980 году. Учитывая, что основа и парадигма программного обеспечения на протяжении долгого времени примерно та же, он пока не утратил своей актуальности. Это можно сравнить со строительством зданий. Конечно, меняются материалы и конструкции, но общие понятия — фундамент, стены, перекрытия — сохраняются.

Согласно тексту Постановления, согласно которому принят данный стандарт, назначение его следующее: «Устанавливает порядок построения и оформления технического задания на разработку программы или программного изделия для вычислительных машин, комплексов и систем независимо от их назначения и области применения».

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

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

Более новый стандарт — ГОСТ 34, но и здесь присутствует нюанс. Новее он только на 10 лет. То есть, введён с 1 января 1990 года.

Формулировка назначения выглядит так: «Распространяется на автоматизированные системы (АС) для автоматизации различных видов деятельности (управление, проектирование, исследование и т. п.), включая их сочетания…».

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

• Общие сведения;
• Назначение и цели создания (развития) системы;
• Характеристика объектов автоматизации;
• Требования к системе;
• Состав и содержание работ по созданию системы;
• Порядок контроля и приемки системы;
• Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;
• Требования к документированию;
• Источники разработки.

Разумеется, за прошедшее время подходы были пересмотрены. Введены новые правила и рекомендации. Сами ГОСТы перешли в разряд базовой опорной точки, а конечный результат остаётся на усмотрение составителей. Тем не менее, при работе с госзаказчиками необходимо брать за основу именно ГОСТ.

ISO/IEC/IEEE 29148

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

Последняя редакция — ISO/IEC/IEEE 29148:2018, но, к сожалению, она отсутствует в открытом доступе, поэтому возьмём за основу предыдущую, от 2011 года.

По аналогии с ГОСТами, стандарт содержит два раздела. Один из них, SyRS — System Requirements Specification — определяет общие требования к построению систем, их принципам и характеру взаимодействия пользователя с ними. По похожей схеме составлен ГОСТ 34.

SRS — Software Requirements Specifitaion — по аналогии с ГОСТ 19, содержит требования к конечному программному продукту.

Общая схема строится следующим образом:

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

Порядок документирования требований

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

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

В основном, уместен в контексте продуктов низкой и средней сложности. Например, небольшой сайт, воронка продаж или даже копирайтинг.

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

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

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

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

Виджет обратного звонка для сайта

• Повысьте конверсию сайта на 30%.
• Экономьте на тарифах: от 5 рублей в минуту.
• Настраивайте под ваш сайт. Адаптируйте под все устройства. Тестируйте разные виджеты.
• Используйте гибкие настройки показа.
• Стройте отчеты по звонкам: от показа виджета до ключевого слова.

Технико-коммерческое предложение

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

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

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

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

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

Если в ТКП требования приводятся самые основные, для ознакомления, то при заинтересованности заказчика с ним составляются уже более детализированные перечни требований.

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

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

Технический проект

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

В соответствии с практическими наработками, составляются новые задания и требования — частные технические задания по отдельным подсистемам (ЧТЗ).

Эксплуатация

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

Перед эксплуатацией и во время неё создаются различные регламенты, описания сервисов, инструкции. Актуализируются текущие версии документов.

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

Источник https://www.akbiz.ru/publications/goszakupki/kak-ispravit-oshibki-v-tz-na-zakupku

Источник https://blog.calltouch.ru/kak-sostavit-tz-podrobnaya-instruktsiya-po-sozdaniyu-tehnicheskogo-zadaniya/

Источник

Источник