Программисту во франче часто приходится участвовать в предпродаже (presale). Не знаю, почему это называется «предпродажей» - по мне, так с момента обращения клиента началась продажа. Запросы я делю примерно на две категории: внедрение и сопровождение.
Внедрения в этом тексте касаться не буду, там про другое. Сопровождение – это примерно когда у клиента есть какая-то система, и он хочет в ней что-то улучшить, модернизировать, развить и т.д.
Так вот, клиент звонит/пишет/приезжает и что-то говорит – сделайте мне вот так и вот так. Бывает, всё просто и понятно – надо сделать то и так, как клиент говорит. А бывает смотришь на задачу, и нутром чуешь – не то тебе надо, дружище. Не в этом у тебя проблема. Другое тебе продать надо. Или то, что просишь, но под другим соусом, с другой стороны.
Общий принцип вам известен: надо решать не задачу, а проблему. И продавать, соответственно, решение проблемы. Осталось эту самую проблему увидеть. Как это сделать, имея в наличии один симптом проблемы – задачу, которую принёс клиент?
Конечно, идеально – продать небольшое обследование или аудит базы. Тогда можно узнать намного больше – и проблем, и задач. Но клиент, например, не хочет аудита – по крайней мере, сейчас, ибо нет нужного уровня доверия или бюджета.
Можно, конечно, много раз с ним поговорить и попытаться выяснить кучу подробностей. Но клиента это быстро задолбает, да и вам (программисту во франче) разговаривать особо некогда – вы занимаетесь продажами постольку-поскольку. Основная работа, всё-таки, программировать.
Остаётся гадать по задаче. Посмотреть на неё и определить реальную проблему. Или хотя бы сузить круг возможных вариантов. И разговаривать дальше исходя из предположений. Срабатывает, конечно, не всегда, но есть ли в продажах метод, работающий на 100%? К тому же, с опытом «гадание» выполняется почти на автомате, без особых затрат времени.
У меня за 16 лет работы накопился небольшой перечень проблем и их симптомов, которые клиенты формулируют в виде задач. У вас, наверняка, такой перечень тоже есть – добро пожаловать в комментарии, если не жалко поделиться.
Начнём с простого.
Нужна свёртка базы
Иногда свёртка действительно нужна, по прямому назначению – уменьшить количество данных и размер базы. Но в большинстве случаев или крепкие люди скоро нагрянут, или остатки кривые.
Грядущую проверку можно диагностировать по фразам «очень срочно» и «чтобы ни одного документа не осталось». Соответственно, акцент в дальнейшей продаже надо делать на срочности, готовности работать в выходные по двойной ставке и безо всяких проволочек, вроде анализа.
Про кривые остатки достаточно спросить. Или прямо, или «вы знаете, что после свёртки остатки не изменятся?». Если у заказчика глаз дёрнется, значит угадали. Можно качать в сторону реальных проблем учёта, которые свёрткой не лечатся.
Нужно управление резервами
Если речь о производственном предприятии, то никакое резервирование им, разумеется, не нужно. Их проблема – плохое планирование и управление ресурсами (материалами, готовой продукцией, полуфабрикатами).
Резервирование только усугубит эту проблему. Но как им это объяснить? Я применял два варианта.
Первый – «медвежья услуга». Честно говоришь, что ни хрена им резервирование не поможет, но, если клиент настаивает – сделаем. Вариант так себе, потому что клиенту будет стрёмно снова обращаться именно к вам, признавая свою неправоту.
Второй – совместное моделирование конфликтов резервирования. У них ведь какая реальная проблема? При появлении ресурсов возникает конкуренция, т.е. внутренний конфликт, который разрешается недемократическим способом.
Говоришь – итак, представьте, что у вас есть резервирование. Раньше самый зубастый просто входил в кабинет директора, а выходил с распоряжением о смене приоритетов. Теперь что изменится? Зубастый посмотрит в отчёт, всплакнёт, и не пойдёт к директору? Ну-ну.
Пойдёт точно так же. Только теперь распоряжением дело не ограничится – ещё нужен будет человек с должными правами, который перекинет резервы. Не исключено, что программист или бухгалтер, потому что среди остальных «распорядителя резервов» выбрать не получится – они все ангажированные.
Возражение «так система же не даст» можно отправить к директору – иди, ему скажи, чего ему там система не даст. Если нет договорённостей о приоритетах и, главное, их соблюдения, не поможет никакая система.
В какую сторону качать продажу? В идеале, конечно, предложить комплексный проект по планированию и устранению разрывов в обеспеченности. Если на предприятии постоянные проблемы в распределении ресурсов, то они явно планируются из рук вон плохо. Производят и закупают не то и не вовремя. Не исключено, что полно неликвидов.
Частенько дело конкретно в одном месте – снабжении. Вот в него и направить усилия продажи, предложив нормальные инструменты для организации процесса.
Нужно автоматическое резервирование
Тут немного другой случай. Бывает, просят – не надо нам управления резервами, пусть всё делается автоматически. Заказ клиента вбили – пусть зарезервирует всё, что может. Пришёл материал – пусть «отдастся» просителям резервов. Ну и т.д.
Тут что? Банальная попытка использовать резервирование для расчёта обеспеченности. Люди хотят постоянно видеть, всё ли у них есть для выполнения обязательств – заказов, планов, сроков. Ни в одной типовой конфигурации нет нормального инструмента для ответа на этот вопрос.
Но, при определённой смекалке, можно под это дело приспособить резервирование и получить от него часть ответов – хотя бы обеспеченность заказов.
Продажу в таком случае лучше двигать от частичных ответов к полным – сделать не резервированием, а более адекватными инструментами.
Нужна роль «просмотр всего»
Задача встречается часто. Что она значит? Я встречал три варианта.
Первый – позвали аудитора. Тут никакой проблемы не рисуется, и продавать особо нечего.
Второй – появился некий наблюдатель, вроде СБшника. Или сам решил сидеть пялиться, или заставили. В чём будет реальная проблема? СБшник не знает, что надо смотреть. Даже не так – не знает, что можно посмотреть. Надо ему подсказать, под соусом «в 1С нет нормальных инструментов контроля, система слишком доверчивая».
Что продать? Типовые и нетиповые инструменты контроля работы сотрудников. Вариантов много – время входа/выхода в 1С (вдруг опаздывают или уходят пораньше), консолидированные отчёты по ошибкам (чтобы всё в одном месте видел), акцентированные отчёты по финансовой и коммерческой безопасности (низкие цены продажи, высокие цены закупа, крупные платежи, долги по подотчёту и т.д.), историю изменений в закрытых (или просто прошлых) периодах и т.д.
Третий – высокий руководитель, или даже собственник, решил приобщиться к великому и самостоятельно смотреть данные в 1С. Тут в чём реальная проблема? Чувак знает, что ему интересно посмотреть, но не умеет пользоваться типовыми отчётами. Если попытаться научить – бросит, потому что лень настраивать и смотреть в кучу отчётов.
Лучше предложить консолидированные отчёты по деятельности предприятия. Такие маленькие, аккуратненькие, чтоб всё по делу и на одной странице А4. И, возможно, не в 1С, а на почту.
Запретить менять заказ после проведения
Налицо классическая проблема согласованности. Продавец оформляет заказ клиента, снабженец заказывает требуемое у поставщика, или заказ отдаётся в производство, а потом бац – продавец заходит и что-то меняет в заказе. Бывает, что речь не о заказе клиента, а о плане продаж, или даже о заявке на расходование денег.
В современных типовых конфигурациях эта проблема более или менее решена – есть какие-то статусы/состояния, которые не дают менять то, что ушло дальше по процессу. Кстати, пользователи этих самых, современных конфигураций, чаще просят обратное – дать возможность проще вносить изменения после запуска в работу. Или чтобы последующие звенья могли реагировать гибче и быстрее.
В старых системах, вроде УПП, такого контроля нет. Соответственно, проблема согласованности и изменения данных возникает. Но беда не приходит одна, и запретом изменения проведённых документов её не решить.
Куда выруливать? В сторону управления процессом планирования и диспетчеризации. Есть подозрение, что этот процесс несколько хаотичный, размазанный, а не ритмичный. Как аналоговый сигнал по сравнению с дискретным. Нет чёткого разделения периодов составления планов и их исполнения (заказ – тоже план).
Чтобы навести клиента на эту мысль, можно поспрашивать о проблемах на любом другом стыке между разными подразделениями, когда одни делают документ для других. Производство/снабжение, снабжение/финансы, продажи/снабжение и т.д. Можно ввернуть что-нибудь умное про контроллинг и требования к данным – чтобы ими нормально пользоваться и управлять, должен быть чётко понятен момент актуальности данных. А чтобы он был чётко понятен, его надо фиксировать в системе.
Как минимум, можно предложить не один запрет изменения заказов после проведения, а более или менее универсальную систему статусов, которыми можно пользоваться в любых «пограничных» документах.
Найти, почему «слетело»
Обычно речь о документах старых периодов или изменении важных справочников. Например, изменились цифры в оборотке. Или кто-то поменял состав спецификации и полгода неправильно списывались материалы.
Найти, конечно, надо. Но проблема повторится, и об этом клиенту нужно сказать. Лучше это сделать до того, как будет найдена причина «слетания», конфликт погашен и вожжа вылезла из-под хвоста. Тут лучше действовать параллельно – и текущую проблему решать, и продавать системное решение по недопущению проблемы в будущем.
Реальная проблема тут маячит одна – плохое управление правами доступа. Возможно, как это часто бывает, у кучи людей полные права. Скорее всего, как почти у всех клиентов, нет одного ответственного за выдачу прав доступа. Не исключено, что не настроен автосдвиг даты запрета (в современных конфигурациях) или не назначен человек, сдвигающий дату вручную (в старых конфигурациях).
Нужно клиента напугать, что он увидел лишь первый проблеск реальной проблемы, и вообще так жить нельзя. Если пустить права на самотёк – жди беды. Вплоть до утечки базы, воровства (даже через комплектации), инсайдер может появиться и т.д. И надо всё это срочно починить.
Особой фантазии тут не надо – есть набор типовых инструментов, которые надо настроить. И парочка организационных решений, которые надо помочь принять – например, назначить главного за права доступа и управление границей запрета. Если повезёт, то главный не найдётся – тогда можно предложить свою кандидатуру, даже если вы во франче. Будете принимать заявки на добавление пользователей, изменение прав доступа, отключение после увольнения и т.д. Клиенту спокойно, вам – деньги.
Запустить давно купленную систему
Обычно это CRM, Битрикс, ДО, УАТ, ТОиР, что-нибудь про охрану труда и т.д. В чём тут реальная проблема?
Кто-то хочет, но не может. Этим «немогущим» может быть, в т.ч., директор или собственник. Хочет, чтобы продавцы работали в CRM, а он будет смотреть красивые отчёты. Или хочет, чтобы КАМАЗы ездили с датчиками расхода топлива. Но нет сил, воли, а то и навыков для внедрения.
Тут вижу два варианта.
Плохой и мерзкий – воспользоваться ситуацией, и продать человеку ещё какую-нибудь коробку, для коллекции. Можно даже не что-то принципиально новое, а тот же продукт от другого производителя. Ну, если нравится человеку коробки коллекционировать, что уж тут.
Хороший – помочь понять реальную проблему и решить её. Реальная проблема – в отсутствии воли и навыков внедрения. Вот это и можно продать, в двух вариантах.
Первый – просто проект внедрения. По сути, ровно то, что просил клиент, без умствований.
Второй – помочь вырастить проектника внутри клиента. Не внедренца конкретного CRM, УАТ или Битрикс, а внедренца чего угодно. Продать аутсорсинг наставничества.
Клиент получит и внедрённую старую систему, и решение своей реальной проблемы – дефицита хороших менеджеров.
