Лягушка и вол

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

Мораль у Эзопа простая. Слабый, который тянется за сильным, кончает плохо.

В закупках это происходит на этапе технического задания.

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

• Инициатор дописывает требование, потому что «в прошлый раз привезли не то».
• Служба безопасности добавляет свое, на всякий случай.
• Кто-то вспоминает про сертификат, который нужен был в позапрошлой закупке.
• Юрист просит расширить гарантию, чтобы точно закрыть риски.

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

А потом лягушка лопается.

Как выглядит взрыв

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

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

Что помогает не лопнуть

• Требуйте обоснование на каждое требование. Не «зачем это надо», а конкретно: какая проблема закрывается и что случится, если убрать. Половина пунктов отваливается на этом вопросе сама.
• Считайте цену после каждой правки, а не в конце. Тогда видно, какое именно требование стоит миллион.
• Прикидывайте, сколько поставщиков остается. Если меньше трех, это уже не подстраховка, а описание конкретной модели.
• Отделяйте «нужно» от «хотелось бы». Второе выносите в оценку заявок, а не в допуск.

Лягушка не была виновата в том, что она маленькая. Она погибла оттого, что не остановилась.

Техзадание можно раздуть. Бюджет нельзя.