{"id":13836,"url":"\/distributions\/13836\/click?bit=1&hash=b61ea41d40ef5596d91409ad89303e69391b638d48696dedc08253272b41c2c3","title":"\u041a\u0430\u043a \u043f\u0435\u0440\u0435\u043d\u0435\u0441\u0442\u0438 \u043d\u0430 \u0441\u0432\u043e\u0438 \u0441\u0435\u0440\u0432\u0435\u0440\u044b \u0430\u043d\u0430\u043b\u043e\u0433\u0438 Google Workspace \u0438 Slack","buttonText":"\u0423\u0437\u043d\u0430\u0442\u044c","imageUuid":"728ad728-b270-5f6e-aa5a-d8a9339fb1b2","isPaidAndBannersEnabled":false}

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

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

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

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

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

Предыстория

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пилот 2

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

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

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

Выводы

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

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

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

Виктор Андреев
0
35 комментариев
Написать комментарий...
Viktor Mann

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

Ответить
Развернуть ветку
Степан Чельцов

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

Ответить
Развернуть ветку
IA F

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

Ответить
Развернуть ветку
Степан Чельцов

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

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

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

Ответить
Развернуть ветку
Александр Леонов

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

Ответить
Развернуть ветку
Александр Леонов

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

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

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

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

Ответить
Развернуть ветку
IA F

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

Ответить
Развернуть ветку
Vl Al

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

Ответить
Развернуть ветку
IA F

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

Ответить
Развернуть ветку
Vl Al

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

Ответить
Развернуть ветку
IA F

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

Ответить
Развернуть ветку
Vl Al

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

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

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

Ответить
Развернуть ветку
Степан Чельцов

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

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

Ответить
Развернуть ветку
IA F

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

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

Ответить
Развернуть ветку
Alexander Smolokurov

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

Ответить
Развернуть ветку
Андрей Спасский

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

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

Ответить
Развернуть ветку
Alexander Smolokurov

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

Ответить
Развернуть ветку
Андрей Спасский

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

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

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

Ответить
Развернуть ветку
Alexander Smolokurov

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

Ответить
Развернуть ветку
Виктор Андреев
Автор

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

Ответить
Развернуть ветку
Андрей Спасский

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

Ответить
Развернуть ветку
Виктор Андреев
Автор

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

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

Ответить
Развернуть ветку
Alexander Smolokurov

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

Ответить
Развернуть ветку
Виктор Андреев
Автор

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

Ответить
Развернуть ветку
Alexander Smolokurov

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

Ответить
Развернуть ветку
Виктор Андреев
Автор

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

Ответить
Развернуть ветку
Степан Чельцов

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

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

Ответить
Развернуть ветку

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

Развернуть ветку
Дмитрий Красавцев

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

Ответить
Развернуть ветку
Виктор Андреев
Автор

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

Ответить
Развернуть ветку
Виктор Андреев
Автор

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

Ответить
Развернуть ветку
Виктор Андреев
Автор

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

Ответить
Развернуть ветку
Дмитрий Красавцев

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

Ответить
Развернуть ветку
Дмитрий Красавцев

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

Ответить
Развернуть ветку
Виктор Андреев
Автор

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

Ответить
Развернуть ветку
Дмитрий Красавцев

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

Ответить
Развернуть ветку
Читать все 35 комментариев
null