Марк Тьюрин – Сделка с организацией: Пошаговый путь поставщика к первому контракту (страница 1)

Марк Тьюрин

Сделка с организацией: Пошаговый путь поставщика к первому контракту

Почему организации покупают не продукт, а предсказуемый результат

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

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

— Сколько времени у нас займёт переход?

— Обычно две-три недели на один объект, — ответил Андрей.

— А если сотрудники не будут вносить данные?

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

Марина пролистала несколько страниц.

— Вы продаёте программу?

— Сервис автоматизации складского учёта.

— Я спрашиваю не о названии. Что изменится у нас через месяц после запуска?

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

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

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

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

Характеристика, выгода и результат

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

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

Но результат звучит иначе: «Вы берёте горячий обед на смену и получаете его тёплым через шесть часов, не рискуя залить документы в рабочей сумке». Результат связан с ситуацией, временем, риском и конкретным действием пользователя.

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

Разницу удобно проверять вопросом: «Что заказчик сможет сделать, получить или перестать терять после покупки?»

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

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

Характеристика «обучение сотрудников» превращается в выгоду «персонал умеет работать в системе». Результат: «Новый кладовщик осваивает приёмку за одну смену по короткому сценарию и не зависит от единственного опытного сотрудника».

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

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

Проверка на примере «Северного учёта»

Первая версия предложения Андрея выглядела так:

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

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

Андрей мог бы перевести предложение в рабочую гипотезу так:

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

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

В новой формулировке появились четыре элемента.

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

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

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

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

Кто чувствует проблему, а кто принимает решение

Андрей сначала думал, что его собеседник — Марина. Она отвечает за закупки, значит, именно ей нужно доказать ценность сервиса. После первой встречи Ирина Белова, операционный руководитель «Северного учёта», задала ему простой вопрос:

— А Марина сама каждый вечер сводит остатки?

— Нет, наверное, этим занимаются управляющие магазинов.

— Тогда почему ты рассказывал ей о скорости работы кладовщика?

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

Для поставщика полезно различать пять ролей.

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

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

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

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

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