Алексей Моргачев
Проектные продажи без воды

ПРОЕКТНЫЕ ПРОДАЖИ

БЕЗ ВОДЫ

Сделка как проект: люди, техника, деньги и время

в сложной B2B-продаже

Алексей Моргачев

2026

Аннотация

В сложной B2B-продаже сделка редко решается одной встречей, одним ЛПР или последним раундом переговоров. Решение проходит через проектировщиков, технических специалистов, бюджет, закупку, подрядчиков, монтаж и эксплуатацию. Иногда продажа проиграна ещё до того, как продавец увидел тендер.

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

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

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

© Алексей Моргачев, 2026

Содержание

Вместо предисловия 1

Час первый. Перестаньте продавать товар 6

Час второй. Клиент — это система 12

Час третий. Найдите проект раньше закупки 22

Час четвёртый. Выйдите из кабинета 31

Час пятый. Переведите технику в деньги 38

Час шестой. Спецификация — ещё не победа 49

Час седьмой. Встреча должна что-то изменить 57

Час восьмой. Не спрашивайте менеджера: «Ну что там?» 63

Час девятый. Поставка ничего не заканчивает 71

Сквозной кейс. От закрытой двери до системы поставок 79

Час десятый. Учитесь на живых сделках 87

Вместо заключения 97

Благодарности 99

Практический комплект проектного продавца 101

Рабочий лист 1. Паспорт сложной сделки 101

Рабочий лист 2. Карта влияния 102

Рабочий лист 3. Встреча: до и после 104

Рабочий лист 4. Разбор победы или проигрыша 105

Об авторе 106

Как пользоваться этой книгой

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

«Час» в этой книге — не обещание ровно шестидесяти минут чтения. Это один практический блок. Его смысл появляется не тогда, когда глава прочитана, а когда вы проверили её на собственной сделке.

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

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

Вместо предисловия

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

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

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

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

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

В какой-то момент я понял, что привычное слово «продажа» слишком упрощает то, чем мы на самом деле занимаемся.

Сложная сделка — это проект.

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

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

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

Эта книга выросла именно из таких ситуаций. Здесь не будет попытки описать вообще всё, что существует в продажах. Мне не хочется делать ещё один учебник на несколько сотен страниц, который человек поставит на полку после первых тридцати. Гораздо интереснее дать несколько принципов, после которых менеджер по-другому посмотрит на собственные сделки.

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

Книга написана прежде всего для менеджера, который ведёт сложные B2B-сделки, но у неё есть ещё два естественных читателя. Инженеру или техническому специалисту она помогает увидеть коммерческую сторону проекта, а руководителю — понять, как разбирать сделки и развивать людей без постоянного «ну что там?». Поэтому в одних главах я говорю с продавцом, в других — с руководителем или инженером. Это не смена аудитории, а три взгляда на одну и ту же систему.

Читать их лучше не как теорию. Возьмите одну настоящую сделку из своей CRM — желательно ту, в которой сейчас не всё понятно. После каждой главы возвращайтесь к ней и проверяйте не то, что записано в карточке, а то, что происходит в реальности.

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

Паспорт сделки

На время чтения заведите один рабочий лист. Это не новая форма отчётности, а карта одной живой сделки. Держите в ней только то, что помогает действовать:

• задача клиента и применение решения;

• стадия проекта, контрольные даты и источник информации;

• участники, их интересы, влияние и отношение к решению;

• техническое решение, ограничения, документация и комплектность;

• экономика, бюджет и маршрут закупки;

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

• риски и неизвестное;

• последний подтверждённый факт и следующий шаг: кто, что и к какой дате делает;

• результат реализации и урок для следующей сделки.

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

Начнём с самого очевидного — с товара.

Час первый. Перестаньте продавать товар

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

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

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

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

Один и тот же запрос может означать совершенно разные продажи. В первой ситуации человеку действительно нужен товар. Во второй — решение задачи.

Запрос клиента и его задача — не одно и то же

У продавца есть естественное желание как можно быстрее получить определённость. Клиент назвал изделие — прекрасно, можно готовить коммерческое предложение. Особенно когда вокруг план продаж, звонки, CRM и ещё десять запросов.

Но в проектной продаже иногда полезно не торопиться. Что человек собирается сделать? Где это будет установлено? Есть ли рабочая документация? Кто проектировал решение? Кто будет монтировать? Какое оборудование устанавливается? Какие ограничения существуют на объекте? Есть ли уже принятое техническое решение?

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

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

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

Для сложной B2B-продажи это огромная сила. Поэтому мне всегда немного странно противопоставление «инженер или продавец». В проектной продаже техническая и коммерческая части не конкурируют друг с другом. Просто одной инженерной компетенции недостаточно так же, как недостаточно одной коммуникабельности.

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

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

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

Поэтому скрипт — начальная точка, а не вершина профессии. Сначала человек учится разговаривать по структуре, а потом должен научиться понимать, когда от неё отойти.

Обратная сторона инженерной экспертности

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

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

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

Иногда самый профессиональный ответ звучит очень просто: «Я сейчас точно не отвечу. Уточню у технического специалиста и вернусь». Такой ответ не уменьшает доверие. Нередко наоборот.

Сначала надо понять, кем должен стать инженер

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

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

Поэтому вопрос «как научить инженера продавать?» слишком широкий. Сначала надо понять, куда именно мы хотим его привести.

Где заканчивается товар и начинается решение

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

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

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

Техническое решение должно быть понятно не только инженеру

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

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

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

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

Что проверить после первого часа

1. Какую задачу решает клиент — за пределами названия товара?

2. Каких технических данных не хватает для честного предложения?

3. Где заканчивается ваша компетенция и кого надо подключить?

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

Час второй. Клиент — это система

Когда продавца учат искать ЛПР, ему предлагают довольно удобную картину: найдите человека, который принимает решение, поймите его интересы, убедите его — и сделка пойдёт дальше. Для простой продажи этого иногда действительно достаточно. В крупной B2B-сделке такая логика быстро начинает ломаться.

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

Поэтому выражение «найти ЛПР» я воспринимаю как полезное упрощение для начала обучения. В реальной сложной продаже одного человека, который единолично принимает всё решение, может вообще не существовать. Гораздо полезнее задать другой вопрос: какую часть решения контролирует каждый участник? Именно с этого начинается нормальная карта сделки.

Один продукт покупают разные люди

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

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

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

Должность даёт гипотезу, но не ответ

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

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

Поэтому должность — это начало разговора, а не готовая карта. Надо понимать, что для человека важно именно сейчас, за что он отвечает, кому сам должен объяснять решение, чего опасается и где у него есть реальные полномочия. Только после этого должность превращается в роль внутри сделки.

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

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

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

Менеджер обычно описывает такую ситуацию словами: «Неожиданно появился ещё один человек». Я бы сформулировал иначе: мы просто не до конца построили карту сделки.

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

Есть ещё одно заблуждение: будто входить в компанию обязательно надо сверху. Сначала директор, потом заместители, потом руководители подразделений.

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

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

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

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

Проектировщик покупает возможность нормально спроектировать

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

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

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

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

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

Это не означает, что ПТО всегда принимает коммерческое решение. Но для продавца оно может стать очень сильным информационным узлом.

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

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

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

Проблема возникает не тогда, когда закупка спрашивает о цене. Проблема возникает, если к этому моменту ценность решения существует только в голове самого продавца.

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

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

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

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

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

Эксплуатация остаётся с оборудованием намного дольше почти всех остальных участников проекта. Проектировщик выпустил документацию. Подрядчик закончил монтаж. Проектная команда сдала объект. А эксплуатация осталась.

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

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

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

Карта коммерческого контура

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

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

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

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

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

Ещё один полезный приём — отмечать качество знания. У меня было три рабочих состояния: знаем и понимаем, знаем, но не понимаем реальную роль, не знаем. Это дисциплинирует. Фамилия в телефоне ещё не означает, что вы понимаете влияние человека. А пустое место на карте лучше красивой догадки, потому что оно превращается в конкретную задачу.

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

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

Что проверить после второго часа

1. Кто реально влияет на техническое, финансовое и закупочное решение?

2. Где у вас факт, а где только гипотеза о роли или отношении человека?

3. Какой важный участник пока отсутствует на карте?

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

Час третий. Найдите проект раньше закупки

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

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

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

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

В проект можно войти слишком поздно

Меня иногда спрашивают, на какой стадии лучше начинать работу по проекту. Мне ближе другой вопрос: когда уже поздно?

Понятие «слишком рано» в проектных продажах достаточно условно. Если проект только планируется, это не означает, что менеджеру надо каждую неделю беспокоить клиента. Работа просто будет иметь другую интенсивность.

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

Главное преимущество раннего входа — не возможность как можно дольше общаться с клиентом. Главное преимущество — время для действий.

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

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

Особенно хорошо это видно на тендерах. Менеджер видит объявленную процедуру и говорит: «Появилась новая возможность». Я бы сначала спросил: кто работал с этой возможностью раньше?

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

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

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

Отмотайте закупку назад

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

Чтобы понять, где на самом деле начинается возможность, полезно мысленно отмотать готовую закупку назад. Закупщик получил заявку. До заявки была спецификация. До спецификации — рабочая документация. До документации — техническое решение. До технического решения существовали исходные данные, задача и проектирование. А ещё раньше кто-то вообще решил, что надо построить, реконструировать или модернизировать объект. Вот это и есть проектный маршрут.

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

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