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

Материал особенно актуален для компаний, которые заходят в крупные B2B-проекты, тендеры, закупки и пилоты с формальными требованиями: лицензиями, СРО, требованиями к персоналу, сроками, SLA, обеспечением контракта и документами, которые нужно предоставить в точном виде.

Анна Шевцова, директор по развитию бизнеса компании «Телесейлз Сервис», рассказала редакции о проекте, который мог принести компании около 50 млн рублей, но сорвался из-за одного пропущенного требования в документации заказчика.

Критическое требование касалось лицензии. По словам Анны Шевцовой, на старте такие условия должны проверять тендерный и технический отделы в связке. После этого случая компания включила в чек-лист цели пилота, KPI, объем работ, сроки, ответственных с обеих сторон, необходимые ресурсы, технические требования и юридические аспекты.

Ошибка стоила дорого: компания потеряла потенциальный проект на 50 млн рублей, около 1 млн рублей на покупку лицензий и подготовку инфраструктуры, около 200 тыс. рублей на подбор и обучение команды, а также 20 дней работы специалистов.

Ошибка была не только в лицензии

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

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

Такое часто происходит именно на старте сильных B2B-проектов: клиент заинтересован, сроки поджимают, пилот выглядит многообещающе, и внутри компании включается логика «давайте быстрее начнем». Но пилот не должен становиться способом закрыть глаза на требования. Он нужен, чтобы проверить гипотезу, риски и готовность сторон. Похожую управленческую логику мы разбирали в статье о том, как запускать пилот изменений, чтобы не ломать работающую систему.

Какие пункты чаще всего пропускают

Опасные пункты редко выглядят опасными. Они спрятаны в стандартных разделах, приложениях, отсылках к нормативным документам или формулировках, которые менеджер читает «по диагонали».

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

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

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

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

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

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

Майя Корецкая советует смотреть не только на очевидные слова «обязан» и «должен», но и на формулировки:

• «является основанием для отклонения»;
• «обязательно должно быть предоставлено»;
• «обязательные требования к участнику закупки»;
• «условия допуска заявок участников»;
• «требуется предоставить».

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

Кто должен проверять ТЗ

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

Оптимальная проверка должна быть многоуровневой. У каждого участника должна быть своя зона внимания, а не общее поручение «посмотрите документы».

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

Здесь важно помнить: ответственность нельзя размазывать между отделами. У процесса проверки должен быть один владелец результата. Иначе каждый посмотрит «свою часть», а критический пункт останется между зонами ответственности. О том, как такие разрывы замедляют бизнес и размывают ответственность, мы писали в материале о том, почему компания вязнет в согласованиях.

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

Когда проект нужно поставить на паузу

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

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

Пауза нужна, если:

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

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

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

Что делать, если ошибку нашли уже после старта

Первое правило — не продолжать молча и не наращивать потери. Если несоответствие уже найдено, нужно сразу фиксировать ситуацию письменно.

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

Эксперты советуют действовать по шагам:

1. Остановить новые расходы. Не покупать лицензии, не нанимать людей и не расширять инфраструктуру, пока не понятно, можно ли спасти проект.
2. Письменно уведомить заказчика. Описать, какое несоответствие обнаружено, к какому пункту документации оно относится и какие варианты решения возможны.
3. Оценить характер требования. Если это внутреннее правило заказчика, можно обсуждать корректировку условий. Если это требование закона, его нельзя «обойти договоренностью».
4. Не выполнять дополнительные работы без письменного согласования. Лучше оформить дополнительное соглашение к договору.
5. Зафиксировать расходы и потери. Это важно, если вопрос перейдет в переговоры, претензию или суд.
6. Быстро принять решение: исправляем или выходим. Если лицензии нет, а требование жесткое, продолжение проекта может только увеличить ущерб.

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

Не только лицензия: еще два коротких примера

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

Мини-чек-лист перед запуском крупного проекта

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

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

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