В основном предприниматели сталкиваются с проблемами в продажах. Они пытаются разобраться, что же происходит у продавцов, но продавцы на всё имеют своё мнение, и в результате не получается объективной оценки. Для перевода из субъективной оценки в объективную (в цифры) требуется всё свести в единую систему. Поэтому заводят CRM.
Об этом давайте сегодня поговорим.
Кто-то выбирает амоcrm, кто-то нишевые решения, кто-то Битрикс 24, но это покрывает только отдел продаж. Продавцы продают товар или услугу, а как проходит процесс выполнения обязательств никто не знает, это происходит уже где-то за скобками.
А что дальше будет с продажей?
Сколько раз после первой продажи покупал клиент?
Изменилась ли стоимость покупки в процессе работы с клиентом?
Предыстория
В новом проекте мы заметили такую же сложность. В целом компания работает хорошо, продаёт хорошо, но что с заказчиком происходит дальше уже ведётся в целом наборе таблиц и чатов т.к. процесс работы вынесен за пределы CRM.
Если в реальном примере, то продажа идёт в Битрикс, а процесс продажи ведется в гугл таблицах. В саму таблицу записывается вся необходимая информация при работе с проектом. Передача информации между исполнителями проекта происходит в чатах мессенджеров, по этому реализация очень не прозрачна.
Начнём с общего плана наступления
В любом проекте мы начинаем с общей схемы. Для этого всегда нас выручает сервис Miro. В нём уже большой багаж наработок по внедрению:
В новом проекте планируем связать всё что есть в компании.
В отделе продаж есть несколько направлений работы:
- Услуга под ключ
- Аренда
- Проработка холодных звонков
- Проработка заказчиков на повторное обращение
- Автосервис
- и ещё пара направлений.
С этим в целом понятно. Делим воронки по направлениям и создаём воронки исполнения обязательств. Получаем вот такую схему для отдела продаж:
После этого детализируем все интеграции с рекламными системами, отчётами, аналитикой и базами ретаргетинга.
Дальше самое интересное.
В отделе продаж мы отделили этап продажи от этапа реализации и выделили отдельную воронку для апсейлов тому же клиенту. Теперь нам требуется определить с кем, и кто взаимодействует при выполнении заказа. Для себя мы выбрали путь собеседований. Простроив график совещаний с каждым отделом, начали описывать кто чем занимается. Получилось 12 отделов при работе с заказом.
- Отдел продаж
- Отдел логистов
- Отдел инженеров
- Отдел снабжения
- Отдел бухгалтерии
- Отдел работы с подрядчиками
- Отдел работы с клиентами
- Отдел первичных документов
- Отдел руководства
Мы шли по взаимосвязи с отделом продаж. т.е. при обсуждении узнавали кто, что готовит для отдела продаж или для выполнения проекта.
Например: для выполнения заказа продавцу требуется оценить перевозку материалов, техники или нужно арендовать технику. В компании есть особые люди для этого.
А логисту требуется ответ от отдела эксплуатации по свободным автомобилям или ресурсам.
В поисках точек соприкосновения отделов и распутывая клубок находили людей, функции которых даже для руководителей были сюрпризом. В результате получили огромную схему взаимосвязей.
Одни продают, другие ищут технику, третьи обслуживают и выдают технику, пятые сопровождают всё документами, следующие оплачивают подрядчиков, седьмые собирают оплату с клиентов… В общем как пчёлки трудятся на общее благо. При этом информация ходит из уст в уста, в переписках, в общем понять кто, что сделал и когда это было достаточно сложно.
Схема схемой, но надо чтоб работало.
Поняв взаимосвязи и описав информацию, которая ходит между отделами мы принялись за пилот.
Пилотным называется временный проект, предназначенный для проверки жизнеспособности уникального предложенного решения.
По сути, задача выглядела так:
Каждый отдел работает над своим кусочком проекта и при этом видит необходимые водные для выполнения своих задач. Мы нашли решение для этого.
Давайте рассмотрим первую версию пилота.
Представим, что у нас пришла заявка на перевозку трактора. Я как продавец узнаю вводную информацию от клиента, описываю её в сделке, а после этого мне надо получить оценку стоимости от логиста (который подберёт технику, оценит работу по перевозке или использует собственную технику). Описав вводные для логиста, передвигаю сделку в статус «Оценить».
При передвижении в оценку создаётся вторая сделка (дочка) в воронке логистов. При этом в сделке у продавца прописывается дочка и её статус.
В воронке логистов появляется сделка, связанная со сделкой в отделе продажи и логист принимает её в работу. Он ищет подрядчика или просчитывает стоимость использования собственной техники. После определения себестоимости логист передвигает сделку на согласование.
В этот момент у продавца сделка передвигается в статус «оценка готова» т.е. логист всё оценил и можно сообщить заказчику стоимость и сроки. При этом у нас есть вся информация в основной сделке и часть информации в сделке для логистов. Теперь отделы работают каждый со своей частью и при этом вся информация копится в единой сделке.
В результате мы знаем:
- Кто из отдела логистики делал оценку
- Сколько по времени заняла эта оценка
- Какую цену он дал
- Что спланировал по этому проекту инженер
- Менеджер знает в каком статусе запрос на оценку
- При реализации проекта каждый в курсе что происходит
А руководитель видит общую картину происходящего.
Посмотрев пилот мы с заказчиком убедились в работоспособности общей идее. Продумав детали, мы усложнили пилот!
Пилот 2
Теперь понятно, что логист с продавцом могут выполнять заказ или продажу работая по отдельности, но сохраняя информацию в системе. Но!
У логистов есть постоянные подрядчики или единоразовые запросы. Каждый раз логист идёт за информацией в телефонную книжку, в записи гугл док или обзванивать новых подрядчиков. После этого отвечает продавцу, и новая заявка повторяет этот процесс. Напрашивается база подрядчиков за всю историю с ценами, оценками качества и пометками. Итого получаем справочники, которые заполняются при каждой оценке проекта и хранятся как база данных по подрядчикам.
Мы сделали второй пилот и он проходит обкатку уже самими отделами. О деталях я расскажу в следующий раз. Да и в целом после пары функциональных пилотов перенесём всю схему взаимодействий, но уже понятно, что отделы могут совместно работать над проектами.
Выводы
Отделять отдел продав в CRM от всех компании не нужно. Можно и нужно настроить взаимосвязи с остальными отделами. После этого вы всегда сможете разобраться в ходе проекта от продажи и до закрытия обязательств.
Кто участвовал в проекте, над чем он работал, какую информацию давал, сделали ли выплаты подрядчикам, как отработали подрядчики на проекте, сколько техники было задействовано, на сколько увеличился чек при реализации, а самое главное связать это всё с источником первого обращения заказчика в компанию.
Вам в работу просится Планфикс.
Вот тоже так подумал. Столько всего решилось бы за 5-10 минут.
Степан, ну зачем так "обнадеживать" 5-10 минут. Как бы в спешке дров не наломать.
Да какие-то вопросы можно решить намного быстрее, но самое главное не пускаться в настройку без разработки ТЗ или хотя бы концепции настройки.
Очень часто приходится сталкиваться с ситуацией когда за кажущейся простотой настройки (кстати это один из факторов почему многие бухгалтера в конце 90-ых стали "программистами 1С", потому что там все было просто) скрывается много ошибок. Потому что просто неправильно используют сущности, не "по назначению". А потом упираются в логические ограничения.
Исхожу из того, что автор умеет структурировать мысли и желания, доски в Миро тому доказательство.
А значит в его руках такой инструмент, как Planfix, раскроется в полной мере.
Но всем тем, кто не так подкован надо следовать вашему совету, согласен.
+1 за ПланФикс
Пользуюсь ПланФиксом потому, что там в отличии от Б24 нет «лишних кнопок».
Со временем начинаешь разбираться в настройках и самостоятельно собирать нужные данные, делать любые отчеты, воронки и тд. В ПланФиксе навыки программиста не нужны.
ПланФикс по функционалу круче, понятней, экономически целесообразней.
Б24 популярен за счёт огромного рекламного бюджета. Но не является лучшим продуктом технически.
Для меня тоже Б24 показалась избыточной. Часто смотрю ролики от интегратора Б24 как раз тут на vc вывешивают. Вроде все логично объясняют, но как запомнить всю эту последовательность действия и как потом это тиражировать не понятно.
Я в свое время отказался от работы в проектах 1С потому что там сложность решений стала "неимоверной". Мозг просто не в состоянии удержать все связи, логику и алгоритмы.
"Мозг просто не в состоянии удержать все связи, логику и алгоритмы." - На платформе один-це просто технически невозможно слепить сап. И практически невозможно. Где доходы одинэсников и где доходы спецов по SAP.
В тех проектах что у меня были, никто не ставил делать САП. Для меня это какая-то не понятная бизнес-цель.
Я как раз сторонник подбирать наиболее подходящее отраслевое решение и вносить минимальные правки.
Опять же причем тут "доходы специалистов". Мы вроде рассуждаем о подборе системы подходящей под решение обозначенных автором задач.
"Опять же причем тут "доходы специалистов" - Мы же думаем чутка вперед. Хотя бы на полгода. Допустим, "система" успешно развернута и введена в эксплуатацию. А кто будет поддерживать "систему" в рабочем состоянии? - У меня так-то больше доверия к спецу, который получает 150 крабов. А спецу за 50 крабов на "систему", грубо говоря, насрать.
А насколько это бизнесово переплачивать за систему и за специалиста, только потому что, возможно, более дорогому специалисту будет не "нас...".
На тех проектах которые я "выпустил" в свое время как руководитель проектов и бизнес аналитик нет потребности в дорогих специалистах и в постоянном допиливании функционала.
Но конечно это от масштабом бизнеса зависит и от стратегии автоматизации.
Системы очень быстро устаревают, и делая проект новой системы, ужа в начале надо понять когда придется её менять.
"А насколько это бизнесово переплачивать за систему"
В случае один-це техническая поддержка производителя работает с девяти до шести вечера (ГМТ +3). Минус суббота и вс.
Собственно, это все, что вам нужно знать про один-це и братцев-армянцев Нургалиевых.
Посмотрите Планфикс, как писали выше. Настройка простая, главное поймать идею настройки. А там уже и воронки сделаете, и разделите процессы на причастных, и делегировать просто будет, и людей менять в процессах без заморочек.
Ну и стоимость внедрения низкая. В Б24 почему-то сразу миллионы начинают мелькать в сметах, а тут вы сами без программиста все настроить, а где не справитесь, за считанные часы Интеграторы помогут сделать.
Выводы "правильные". Если есть возможность внедрять комплексную систему то надо это делать. Основная проблема в том что к выбору системы очень часто подходят не правильно. Выбирают "на эмоциях и чуйке", не используя подход подбора по функциональным требованиям.
Тут уже кто-то написал про ПланФикс. То что описано в статье можно через него сделать.
Для примера в моем самом первом проекте который я делал используя именно планфикс (а задача была такая же как у вас выбрать единую систему управления взаимосвязанными процессами), я провел анализ порядка 10 различных систем (не глубокий анализ, но въедливый) и еще систем 20 были на примете (поверхностный анализ). Все системы оценивались как раз через таблицу функциональных требований (не знаю допускается ли здесь вставка видео, если кто-то напишет то вышлю в личку ссылку видео о выборе системы по функциональным требованиям). И победил ПланФикс.
Будет ли это проще чем в Битрикс 24, мне сложно судить, с б24 мало работал, хотя пытался делать несколько заходов (но у меня фриланс, команда не большая, проекты не длинные).
В общем Виктор вам терпения в поиске "вашей системы".
В Б24, где, судя по всему, предпринимается попытка это всё реализовать, есть крупный косяк: по их логике "заключенная сделка" = "завершенная сделка". То есть, вся работа по обслуживанию должна проводиться в рамках ещё незаключенной сделки, иначе при смене статуса сделки все задачи по ней будут автоматически закрыты.
Ну, и с отчетностью в схеме "сделка по сделке" будут косяки. Потому что отчетность Б24 не поддерживает фильтрацию по вложенности сделок. Снова костыли подставлять придется.
1) Это может быть проблемой, если пытаться заложить весь детальный жизненный цикл сделки в одну воронку (продажу, производство, контроль качества и тд). Тогда, действительно, получится портянка и "заключенная сделка" будет = "завершенная сделка". Это обычно решается созданием отдельных воронок для отдельных этапов жизни сделки.
2) А какого функционала в Б24 изначально достаточно при реализации сложных проектов?) Всё так или иначе приходится допиливать, но ведь главное, чтобы цель была достигнута?
Какого рода косяки Вы предполагаете в возможных отчетах?
Я, конечно, не пытался досконально разбираться в схеме "сделка по сделке", но, учитывая плоскую систему аналитики Б24, логично предположить, что со связями сущностей будут проблемы. Особенно в управленческом учёте.
Дальше фантазийный пример: мне нужно увидеть, сколько и каких сделок по обслуживанию просрочил конкретный подрядчик из сделок, заключенных продавцами в означенный период. Если связку "сделка по обслуживанию" - "подрядчик" я смогу отследить, от отделить планируемую дату завершения от реальной даты завершения - уже нет (это не заложено логикой Б24, но можно выкрутиться при помощи задач). И тем более не смогу отфильтровать сделку по обслуживанию по свойству сделки по продаже (ибо свойства сущностей не пересекаются).
Или я как-то не так рассуждаю?
Про ограниченность (мягко говоря) родной аналитики в Б24 не буду спорить, хотя для базовых и средних задач можно и ее адаптировать исключительно штатными средствами)
Конкретно в Вашем примере не вижу проблем, поскольку тут вопрос в обмене данными между несколькими сделками. Это очень распространенный запрос, когда есть несколько связанных сделок, и требуется передавать данные из одних в другие (как правило из дочерних в головную). То есть, фактические даты обработки сделки в производстве/обслуживании легко отдаются в сделку продажника. А настроить поля "Планируемый дедлайн", "Фактический дедлайн" и "Сроки сорваны" - дело пары минут. После чего можно вывести отчет по просрочкам конкретного подрядчика в рамках сделки продажника или сделки производства не составит проблем.
Надеюсь, я верно понял предложенный Вами сценарий?
)) С дополнительными полями - это каждый может! ))) Шучу, конечно. Потому как допполя реально выручают, потому что даже при фиксации некоторых данных самой системой выудить их оттуда стандартными методами просто нереально.
Но с допполями и роботами - да, должно получиться. Сам я не внедренец, а пользователь, потому и рассуждаю на основе опыта. Надо будет тему с вложенными сделками подробнее посмотреть. Спасибо.
Не за что. Если будут вопросы, то задавайте.
Тут фича в том, что эти доп.поля заполняются автоматически и в большинстве своем, как правило, скрываются от глаз пользователя, чтобы не замыливать глаз. А выводятся уже органичными данными в рамках дэшбордов/отчетов/описаний к задачам и тд) Поэтому, да, рассматривать данный сценарий как рациональный можно лишь при соблюдении вышеуказанных условий)
С отчётностями в самом б24 не так всё просто, но и не надо пытаться там строить это всё. Б24 может слушить хранителем информации.
Особенные метки, пометки можно хранить в карточках сущностей и роботами заполнять в нужный момент.
Дальше уже простые отчёты можно выстраивать в б24, а если не достаточно функционала, а часто не всё можно посчитать, то делаем выгрузку и считаем на стороне датастудио или других Bi.
Если проще, то в б24 важно учесть на страте проектирования какие отчёты вы планируете смотреть, заложить хранение, заполнение данных и потом уже оттуда брать в сыром виде.
Да, согласен, можно. Но это время. То есть, Б24 внедряется, вроде бы, для оптимизации процессов. Всех, кроме работы с самим Б24 ))
Что не так с работой в б24?
Дело привычки.
Дело, скорее, не привычки, а умения приспособиться. )) Через выгрузку данных, в том числе. Ну, вот, навскидку: попробуйте вывести любым способом (хоть в списке сущностей, хоть в отчётах) список компаний или контактов без назначенных дел. А это нормальный такой оперативный учёт. Или попробуйте построить отчет объемов сделок по сферам деятельности компаний клиентов. А это стандартный рыночный анализ.
И если рыночный анализ делается периодически и задача решается выгрузкой и сравнением двух баз, то оперативный учёт потому и оперативный, что на него не должно тратиться время. А оно тратится.
Сам отчёт в б24 страдает, но есть много приложений которые выгружают по расписанию. Дата студио онлайн строит отчёт.
Не так сложно решается эта задача и без всяких сравнений баз.
Видел такой отзыв, что люди любят Б24, потому что все можно выгрузить в Гугл.Док и там анализировать, принимать решения и т.п.
На мой взгляд, работать должны роботы, а приниматься решения там, где есть события - системе управления компанией.
Комментарий удален модератором
Можно всё реализовать в Elma
Надо посмотреть
Но в этом случае уже порядка 10 000 контактов, проектов было в б24.
Звучит проще чем кажется. Вы уже пробовали сделать подобное в Elma?
Я занимался автоматизацией бизнес-процессов агентства недвижимости в роли IT директора(менеджера, аналитика, менеджера проекта). В Элме как раз мощный инструментарий по созданию бизнес-процессов, которыми можно связать все подразделения компании.
Сейчас для своего стартапа начал использовать новый продукт Elma365, в ней немного другой интерфейс, но основой является всё тот же движок бизнес-процессов с нотацией BPMN 2.0, просто в нем есть версия Saas
Я бы сказал, что нет такого, что в ней нельзя сделать. Вопрос только как вы умеете работать с изменениями и сотрудниками.
Закажите презентацию у них, покажите консультанту ваш кейс, внедрять можно своими усилиями, можно привлекать партнеров Элмы или самого вендора.
Спасибо посмотрю, но есть подозрение, что многие функции разработанные б24 придётся лепить с 0 в елме. Стоимость разработки наверно космос получится.
если б24 имеет нужный функционал для реализации проекта, то конечно нет смысла менять, если нет, то нужно идти от продукта и создания ценности для потребителя, все процессы описать, найти подходящий инструмент и внедрять. всё просто ;)
в учет нужно брать раздел стратегического развития в бизнес-процессах, чтобы потом не упереться в какую-то "стену".