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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рекомендуем

Узнайте больше про ECM из вебинаров