{"id":4879,"title":"\u0427\u0442\u043e \u043c\u043e\u0436\u043d\u043e \u0443\u0441\u043f\u0435\u0442\u044c, \u043f\u043e\u043a\u0430 \u0432\u044b \u0447\u0438\u0442\u0430\u0435\u0442\u0435 \u044d\u0442\u0443 \u0441\u0442\u0430\u0442\u044c\u044e","url":"\/redirect?component=advertising&id=4879&url=https:\/\/vc.ru\/otpbank\/266952&hash=82572a4a372a00657a2afc359f19a24c0bd24be8cecbd743f0681209c07c9a3a","isPaidAndBannersEnabled":false}

Как оценивать результат работы всей компании? Внедрение «Битрикс24» не только для продаж

В основном предприниматели сталкиваются с проблемами в продажах. Они пытаются разобраться, что же происходит у продавцов, но продавцы на всё имеют своё мнение, и в результате не получается объективной оценки. Для перевода из субъективной оценки в объективную (в цифры) требуется всё свести в единую систему. Поэтому заводят CRM.

Об этом давайте сегодня поговорим.

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

А что дальше будет с продажей?
Сколько раз после первой продажи покупал клиент?
Изменилась ли стоимость покупки в процессе работы с клиентом?

Предыстория

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

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

Начнём с общего плана наступления

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

Схемы внедрений, задумок.

В новом проекте планируем связать всё что есть в компании.

В отделе продаж есть несколько направлений работы:

  • Услуга под ключ
  • Аренда
  • Проработка холодных звонков
  • Проработка заказчиков на повторное обращение
  • Автосервис
  • и ещё пара направлений.

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

Схема воронок для продаж.

После этого детализируем все интеграции с рекламными системами, отчётами, аналитикой и базами ретаргетинга.

На примере две воронки.

Дальше самое интересное.

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

  • Отдел продаж
  • Отдел логистов
  • Отдел инженеров
  • Отдел снабжения
  • Отдел бухгалтерии
  • Отдел работы с подрядчиками
  • Отдел работы с клиентами
  • Отдел первичных документов
  • Отдел руководства

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

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

Взаимосвязь отделов.

А логисту требуется ответ от отдела эксплуатации по свободным автомобилям или ресурсам.

Взаимосвязь отделов.

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

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

Схема схемой, но надо чтоб работало.

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

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

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

Давайте рассмотрим первую версию пилота.

Схема первой версии.

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

При передвижении в оценку создаётся вторая сделка (дочка) в воронке логистов. При этом в сделке у продавца прописывается дочка и её статус.

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

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

В результате мы знаем:

  • Кто из отдела логистики делал оценку
  • Сколько по времени заняла эта оценка
  • Какую цену он дал
  • Что спланировал по этому проекту инженер
  • Менеджер знает в каком статусе запрос на оценку
  • При реализации проекта каждый в курсе что происходит

А руководитель видит общую картину происходящего.

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

Пилот 2

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

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

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

Выводы

Отделять отдел продав в CRM от всех компании не нужно. Можно и нужно настроить взаимосвязи с остальными отделами. После этого вы всегда сможете разобраться в ходе проекта от продажи и до закрытия обязательств.

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

Спасибо, что дочитали до конца. Надеюсь, статья была полезна вам. Остались вопросы? Напишите мне в Telegram (или так ссылка), с удовольствием отвечу.

Виктор Андреев
{ "author_name": "Виктор Андреев", "author_type": "self", "tags": [], "comments": 35, "likes": 8, "favorites": 21, "is_advertisement": false, "subsite_label": "marketing", "id": 258820, "is_wide": true, "is_ugc": true, "date": "Tue, 15 Jun 2021 18:37:14 +0300", "is_special": false }
0
35 комментариев
Популярные
По порядку
Написать комментарий...
12

Вам в работу просится Планфикс.

Ответить
3

Вот тоже так подумал. Столько всего решилось бы за 5-10 минут.

Ответить
1

Степан, ну зачем так "обнадеживать" 5-10 минут. Как бы в спешке дров не наломать.
Да какие-то вопросы можно решить намного быстрее, но самое главное не пускаться в настройку без разработки ТЗ или хотя бы концепции настройки.
Очень часто приходится сталкиваться с ситуацией когда за кажущейся простотой настройки (кстати это один из факторов почему многие бухгалтера в конце 90-ых стали "программистами 1С", потому что там все было просто) скрывается много ошибок. Потому что просто неправильно используют сущности, не "по назначению". А потом упираются в логические ограничения.  

Ответить
1

Исхожу из того, что автор умеет структурировать мысли и желания, доски в Миро тому доказательство.

А значит в его руках такой инструмент, как Planfix, раскроется в полной мере.

Но всем тем, кто не так подкован надо следовать вашему совету, согласен.

Ответить
3

+1 за ПланФикс

Ответить
2

Пользуюсь ПланФиксом потому, что там в отличии от Б24 нет «лишних кнопок». 

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

ПланФикс  по функционалу круче, понятней, экономически целесообразней.

Б24 популярен за счёт огромного рекламного бюджета. Но не является лучшим продуктом технически. 

Ответить
1

Для меня тоже Б24 показалась избыточной. Часто смотрю ролики от интегратора Б24 как раз тут на vc вывешивают. Вроде все логично объясняют, но как запомнить всю эту последовательность действия и как потом это тиражировать не понятно.
Я в свое время отказался от работы в проектах 1С потому что там сложность решений стала "неимоверной". Мозг просто не в состоянии удержать все связи, логику и алгоритмы. 

Ответить
0

"Мозг просто не в состоянии удержать все связи, логику и алгоритмы." - На платформе один-це просто технически невозможно слепить сап. И практически невозможно. Где доходы одинэсников и где доходы спецов по SAP.

Ответить
0

В тех проектах что у меня были, никто не ставил делать САП. Для меня это какая-то не понятная бизнес-цель.
Я как раз сторонник подбирать наиболее подходящее отраслевое решение и вносить минимальные правки. 
Опять же причем тут "доходы специалистов". Мы вроде рассуждаем о подборе системы подходящей под решение обозначенных автором задач.

Ответить
0

"Опять же причем тут "доходы специалистов" - Мы же думаем чутка вперед. Хотя бы на полгода. Допустим, "система" успешно развернута и введена в эксплуатацию. А кто будет поддерживать "систему" в рабочем состоянии? - У меня так-то больше доверия к спецу, который получает 150 крабов. А спецу за 50 крабов на "систему", грубо говоря, насрать. 

Ответить
0

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

Ответить
0

"А насколько это бизнесово переплачивать за систему"

В случае один-це техническая поддержка производителя работает с девяти до шести вечера (ГМТ +3). Минус суббота и вс. 

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

Ответить
1

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

Ну и стоимость внедрения низкая. В Б24 почему-то сразу миллионы начинают мелькать в сметах, а тут вы сами без программиста все настроить, а где не справитесь, за считанные часы Интеграторы помогут сделать.

Ответить
1

Выводы "правильные". Если есть возможность внедрять комплексную систему то надо это делать. Основная проблема в том что к выбору системы очень часто подходят не правильно. Выбирают "на эмоциях и чуйке", не используя подход подбора по функциональным требованиям.
Тут уже кто-то написал про ПланФикс. То что описано в статье можно через него сделать.
Для примера в моем самом первом проекте который я делал используя именно планфикс (а задача была такая же как у вас выбрать единую систему управления взаимосвязанными процессами), я провел анализ порядка 10 различных систем (не глубокий анализ, но въедливый) и еще систем 20 были на примете (поверхностный анализ). Все системы оценивались как раз через таблицу функциональных требований (не знаю допускается ли здесь вставка видео, если кто-то напишет то вышлю в личку ссылку видео о выборе системы по функциональным требованиям). И победил ПланФикс.

Будет ли это проще чем в Битрикс 24, мне сложно судить, с б24 мало работал, хотя пытался делать несколько заходов (но у меня фриланс, команда не большая, проекты не длинные).
В общем Виктор вам терпения в поиске "вашей системы".

Ответить
0

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

Ответить
1

1) Это может быть проблемой, если пытаться заложить весь детальный жизненный цикл сделки в одну воронку (продажу, производство, контроль качества и тд). Тогда, действительно, получится портянка и "заключенная сделка" будет = "завершенная сделка". Это обычно решается созданием отдельных воронок для отдельных этапов жизни сделки.

2) А какого функционала в Б24 изначально достаточно при реализации сложных проектов?) Всё так или иначе приходится допиливать, но ведь главное, чтобы цель была достигнута? 
Какого рода косяки Вы предполагаете в возможных отчетах? 

Ответить
0

Я, конечно, не пытался досконально разбираться в схеме "сделка по сделке", но, учитывая плоскую систему аналитики Б24, логично предположить, что со связями сущностей будут проблемы. Особенно в управленческом учёте.
Дальше фантазийный пример: мне нужно увидеть, сколько и каких сделок по обслуживанию просрочил конкретный подрядчик из сделок, заключенных продавцами в означенный период. Если связку "сделка по обслуживанию" - "подрядчик" я смогу отследить, от отделить планируемую дату завершения от реальной даты завершения - уже нет (это не заложено логикой Б24, но можно выкрутиться при помощи задач). И тем более не смогу отфильтровать сделку по обслуживанию по свойству сделки по продаже (ибо свойства сущностей не пересекаются).
Или я как-то не так рассуждаю?

Ответить
1

Про ограниченность (мягко говоря) родной аналитики в Б24 не буду спорить, хотя для базовых и средних задач можно и ее адаптировать исключительно штатными средствами)

Конкретно в Вашем примере не вижу проблем, поскольку тут вопрос в обмене данными между несколькими сделками. Это очень распространенный запрос, когда есть несколько связанных сделок, и требуется передавать данные из одних в другие (как правило из дочерних в головную). То есть, фактические даты обработки сделки в производстве/обслуживании легко отдаются в сделку продажника. А  настроить поля "Планируемый дедлайн", "Фактический дедлайн" и "Сроки сорваны" - дело пары минут. После чего можно вывести отчет по просрочкам конкретного подрядчика в рамках сделки продажника или сделки производства не составит  проблем.

Надеюсь, я верно понял предложенный Вами сценарий?

Ответить
1

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

Ответить
0

Не за что. Если будут вопросы, то задавайте. 

Ответить
0

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

Ответить
1

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

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

Ответить
0

Да, согласен, можно. Но это время. То есть, Б24 внедряется, вроде бы, для оптимизации процессов. Всех, кроме работы с самим Б24 ))

Ответить
0

Что не так с работой в б24?
Дело привычки.

Ответить
0

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

Ответить
0

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

Ответить
0

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

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

Ответить

Комментарий удален

0

Можно всё реализовать в Elma

Ответить
0

Надо посмотреть

Ответить
0

Но в этом случае уже порядка 10 000 контактов, проектов было в б24.

Ответить
0

Звучит проще чем кажется. Вы уже пробовали сделать подобное в Elma?

Ответить
0

Я занимался автоматизацией бизнес-процессов агентства недвижимости в роли IT директора(менеджера, аналитика, менеджера проекта). В Элме как раз мощный инструментарий по созданию бизнес-процессов, которыми можно связать все подразделения компании.
Сейчас для своего стартапа начал использовать новый продукт Elma365, в ней немного другой интерфейс, но основой является всё тот же движок бизнес-процессов с нотацией BPMN 2.0, просто в нем есть версия Saas 

Ответить
0

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

Ответить
0

Спасибо посмотрю, но есть подозрение, что многие функции разработанные б24 придётся лепить с 0 в елме. Стоимость разработки наверно космос получится. 

Ответить
0

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

Ответить
Читать все 35 комментариев
Wildberries проиграл продавцу суд на 39 млн рублей

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

Поддельные штрафы, «левые» QR-коды и фейковые тесты на ковид. Как защититься от мошенников в сети

Пандемия вдохновила мошенников на новые идеи преступлений в сети. Собрали 10 популярных видов киберпреступности и способы защиты от них.

Роскомнадзор заблокировал сайт с текстами песен Genius.com Статьи редакции

За несколько лет десятки материалов сайта были внесены в список запрещённых в России.

7 советов стартапам по работе с корпорациями

О том, как стартапам предлагать свои разработки крупным корпорациям и оказаться замеченными, рассказывает директор Центра развития новых продуктов Академии Ростеха, трекер фонда развития интернет-инициатив, эксперт в области запуска акселерационных программ и работы с высокотехнологичными стартапами Андрей Батрименко.

Не покупает рекламу, не продаёт акции, не повышает цены: как производитель соуса Huy Fong занял 10% рынка США Статьи редакции

Основатель Дэвид Тран сбежал из коммунистического Вьетнама, открыл свой бизнес в США и достиг выручки в $150 млн в год без торговой марки и маркетинга.

Дэвид Тран с главными символами компании — бутылками соуса шрирачи Huy Fong Foods
Академия Ростеха – о движении Ворлдскиллс Россия и его развитии на предприятиях Ростеха

Академия Ростеха уже на протяжении четырех лет формирует и готовит сборную Госкорпорации к Национальному чемпионату сквозных рабочих профессий высокотехнологичных отраслей промышленности WorldSkills Hi-Tech. О том, как проходит отбор чемпионов на предприятиях, что дает сотрудникам участие в движении и как Ворлдскиллс популяризирует актуальные…

Санкт-Петербургская биржа начнёт торговать акциями онлайн-брокера Robinhood Статьи редакции

Компания запланировала привлечь $2 млрд и продать 55 млн акций по цене от $38 до $42 за штуку.

Джефф Безос предложил покрыть до $2 млрд расходов NASA в обмен на контракт для отправки космонавтов на Луну Статьи редакции

В апреле NASA отдало контракт SpaceX, но в мае приостановило его из-за протеста конкурентов.

Лунный посадочный модуль Blue Moon
Пирамида Finiko собрала миллиарды рублей и рухнула — но это не первый проект её создателя, где люди потеряли деньги Статьи редакции

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

Кирилл Доронин
Цифры в спорте: как выиграть матч еще до его начала
LG представила беспроводные наушники с режимом «шёпота» Статьи редакции

Всего в линейке три модели — для двух в зарядных кейсах встроена ультрафиолетовая лампа.

Наушники FP8 LG
null