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

РОПы не там ищут ошибки и сбои в работе продающих сценариев.

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

Таблица 2. Этапы принятия решения о покупке в корпорации

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

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

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

1. Ищите Прометея внутри компании-покупателя

В нашей стране госкапитализма топ-менеджмент крупных компаний – скорее чиновники, чем предприниматели. А чиновник в силу своего статуса не хочет нести персональную ответственность, он – только часть системы принятия решения. Как в песне: «Скованные одной цепью, связанные одной целью…»

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

Корпоративные чиновники любят работать по правилам, по стандартам, как все. Все внедряют SAP – и мы будем внедрять. Все покупают VR-технологии – и мы будем внедрять. Все занимаются импортозамещением – и мы будем. При этом совершенно неважно, как и чем закончится проект. Главное, чтобы в процессе реализации не было перерасхода бюджета и формальных нарушений закона. А работает это или нет – проблемы рядовых исполнителей.

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

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

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

2. Большинство поставщиков софта не хотят «прогибаться» под клиента

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

В нашей стране В2В-продажи легко идут у тех компаний, которые продают продукты, ставшие по факту стандартом корпоративного офиса: «1С: Бухгалтерия», нормативно-правовые системы «КонсультантПлюс» и «Гарант», программные продукты для офисных сотрудников (Word, Excel, PowerPoint).

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

Снижение уровня принятия решения через снижение величины единоразового месячного платежа позволят бездомным в США покупать себе последние модели смартфонов. На конференциях ФРИИ (Фонда развития интернет-инициатив) любят рассказывать ИТ-байку о том, как новый начальник отдела продаж крупной ИТ-компании в свой первый день на рабочем месте разослал всем клиентом счет на сумму 2555 руб. с формулировкой «за фигню». И 80 % клиентов оплатили его не задумываясь. Благодаря этой инновации план по выручке был выполнен досрочно.

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

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

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

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

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

3. Разочарование в автоматизации, цифровизации, диджитализации

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

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

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

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

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

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

Обоснование 1. «Сотрудники не справляются с текущим объемом работы» (переработки, ошибки)

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

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

Какие бывают количественные драйверы.

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

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

• Для проектов цифровизации производственных процессов – сокращение трудозатрат (если программа позволяет увеличить производительность труда) + сокращение прямых производственных расходов (снижение расхода сырья, своевременное проведение профилактических ремонтов и, как следствие, сокращение затрат на дорогостоящие капремонты).

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

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

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

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

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

Зачем это нужно продавцам?

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

• Он практически гарантирует победу в последующих конкурсах на экономически обоснованное внедрение новых программ.

• Это отличный кейс для других покупателей во время референс-визитов.

Обоснование 2. «Необходимо перейти на другой софт»

• Компания – производитель софта выпустила новую версию, с новым ядром, поэтому предстоит полностью переписать старую кастомизированную версию.

• Производитель софта закрыл свой бизнес в России (санкции, импортозамещение).

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

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

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

По слухам, в 2022 году «ПИК-Комфорт» – управляющая компания для жилищных комплексов на пять месяцев утратила возможность выставлять платежки жильцам из-за ошибок при переносе клиентской базы. Бюджет освоили, работу сдали, а потом бухгалтерам пришлось вручную переносить данные из системы в систему, перевыставлять тысячи счетов и судиться с клиентами.

В борьбе с жадностью собственного начальства мы рекомендуем РОПам помочь будущим клиентам использовать следующие обоснования будущих затрат (количественные драйверы).

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

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

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

Обоснование 3. «Уменьшение рисков для бизнеса»

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

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

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

Качественно составленное коммерческое предложение в крупную современную компанию должно содержать информацию о том, какие риски уменьшатся (трансформируются) после инвестиций в покупку вашего программного продукта.

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

Мы рекомендуем использовать следующий шаблон.

1. Представление ИТ-компании. История успеха.

2. Представление продукта. Какую пользу компании-покупателю он может принести. Расчет стоимости в трех вариантах комплектации (самый дешевый, средний и максимальная комплектация).

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

4. Краткое представление вашей команды внедрения (куратор и руководитель проекта, функциональные эксперты, бизнес-аналитики, программисты и т. д.). Персональный опыт команды внедрения.

5. Подтверждение соответствия вашей ИТ-компании квалификационным требованиям, заложенным в корпоративные тендерные документы (оборот, масштабы предыдущих внедрений, срок присутствия на рынке; квалификационные аттестаты ваших работников, которые будут внедрять продукт, и т. д.).

6. Конкретные внедрения с подтвержденными сроками окупаемости.

7. Предложение о проведении референс-визитов к старым клиентам для подтверждения эффективности внедренного продукта, представление рекомендательных писем.

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

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

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

Раздел 6. Статус, возраст и корпоративная культура как препятствие к заключению сделки

Абсолютное большинство софтверных компаний в России психологически, культурно и терминологически обращено к США, родине всех компьютерных инноваций. Многие ИТ-компании в нашей стране – разновидность карго-культа с американского софтверного бизнеса. Плюс культ молодости, молодые начальники, молодые сотрудники, игры в меритократию.

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

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

Наши доморощенные гении заимствуют в Калифорнии все – от новых программ до легалайза марихуаны вперемешку с криптовалютами.

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

Но хуже всего для продажи софта российским корпоратам – неумелые игры в американскую организационную структуру управления бизнесом. Многие софтверные компании в нашей стране создавались как продавцы светлых голов разработчиков на крупные проекты в США. Это очень выгодно, поскольку существует огромная разница в стоимости оплаты труда американца и россиянина. Чтобы иметь возможность получать супермаржу, было очень важно установить взаимопонимание с американскими заказчиками: хорошо знать язык, соблюдать американские правила и традиции, соответствовать статусу во время деловых переговоров. Полная подстройка под американского суперклиента привела к бестолковому копированию названий должностей, как в благословенной Америке, даже если фактическая суть иная. Так было легче устанавливать контакт с клиентами в США, доверять друг другу, продавать софт и услуги в другие страны.

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

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

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

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

• Он не воспринимает ситуацию всерьез!

• Он просто не понимает, кто перед ним распинается, какие у нее полномочия, какой статус, что за должность и за что она реально способна отвечать.

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

Если нет доверия, нет и сделки!

Если вы думаете, что мы сильно преувеличиваем и мир давно изменился – возраст и статус уже не имеют такого значения, как при царизме, что люди стали более открытыми, а средний возраст топ-менеджеров сильно снизился, то мы с вами согласимся. Да, изменения есть, демократизм в общении стал нормой. Теперь ЛПР в корпорации не спрашивают своих гостей: «Ты чьих будешь, мил человек? От кого пришел, где твои верительные грамоты?»

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

Выводы

Ваши продающие презентации и переговоры станут намного успешнее:

• если вы будете посылать на встречу сотрудника, по возрасту похожего на большинство ЛПР в корпорации. Разница более пяти лет уже мешает взаимопониманию – людям трудно чувствовать себя на одной волне;

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

• если на визитке будут все регалии и полные Ф.И.О. Чтобы во время переговоров обращаться с должным уровнем вежливости и ничего не перепутать.

Бесплатный фрагмент закончился. Хотите читать дальше?