Дмитрий Гончаренко: Сегодня в рубрике Рассказ от первого лица интереснейший пост Сергея Улаева, руководителя компании AffContext, о внедрении ПланФикса на производственном предприятии. У Сергея редкий талант рассказывать о серьезных вещах таким простым языком, что сложно оторваться от чтения. Впрочем, сейчас вы все поймете сами.

Сергей Улаев: Это статья о том, как технически был реализовано внедрение ПланФикса в одной компании (ООО «ИнБетон»), которая занимается производством и продажей фасадного декора по всей России.

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

Итак, погнали.

Ах, да…сразу…Draw.io – так называется сервис, где мы рисуем все схемки ,что вы будете видеть ниже. Знаем, что вы этот вопрос будете вечно крутить в голове в процессе чтения 🙂

И начнём с того, что схематически опишем, как выглядели «каналы взаимодействия» в компании до внедрения. По блокам.

Все входящие заявки с интернета и телефонии попадали в отдел продаж, который работал на тот момент с AmoCRM (которую мы же год назад и внедряли 🙂 )

Линия «AmoCRM» показывает способ коммуникации.

Вертикальная линия как бы разделяет внешний мир от внутреннего мира компании. Стрелка – двухсторонняя, что говорит о том, что информация «бегала» туда-сюда. Клиенты писали \ звонили, это всё падало в AmoCRM. Отдел продаж отвечал также из AmoCRM.

Отдел продаж в процессе работы общается с отделом проектирования. Из важного – обмениваются файлами для расчётов (не берём в учёт общение в мессенджерах для них). Где хранятся файлы?

Конечно, в облаке….
Могли бы подумать вы. Но хрен-то-там. Они хранятся в локальной сети. Они называли его «обменник».

Помните такую вещь?

Фактически, это означает, что файлы хранятся на одном компьютере, к которому имеют доступ другие компьютеры через обычный кабельный провод (вы то в теме, а лет через 5 люди могут и не знать это уже). Процедура передачи проекта на расчёт была такая:

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

«Зато нет привязки к интернету и всё моментально скачивается!» – говорили нам сотрудники компании с гордым лицом. А потом сами же теряли кучу трудо-часов времени, когда они бы рады получить какой-то файл с «обменника», а головной компьютер выключен и запаролен. Всё – простОй в работе. Да и из дома так не поработаешь. В общем, нам на это было страшно смотреть.

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

Тут уже сразу была проблема – не все сделки хранились в AmoCRM изначально. Наверное, из-за малого количества таких сделок эта схема довольно долго жила в компании. Пока не пришли мы ).

Далее – есть отдел «Бухгалтерия». К слову, он здесь достаточно «громко» назван словом «бухгалтерия», т.к. это было больше хранение информации о договорах (да и самих договоров физически) + редкое общение с клиентами по каким-либо вопросам (не касающимся отдела продаж). Никакой 1С, счетов, актов и пр. бухгалтерского документооборота здесь не будет. Вот всё это мы назвали «бухгалтерия». Пусть так и будет.

И вот бухгалтерия общалась с отделом продаж тоже «На словах»:

И это просто бесило отдел продаж. Вот реально – бесило!

– а какой ИНН у этого клиента?
– а какой телефон?
– а почта?
– ой, потеряла телефон, можешь снова сказать его?

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

У бухгалтерии не было доступа в AmoCRM, платить за отдельный аккаунт ради такой информации никто не хотел. Ходят слухи, что ПланФикс и дешевле 🙂

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

– А когда будет готов заказ?
– А сколько сделали?
– А сколько осталось?
– А вообще начали делать?
– А сколько брака?

И так далее…от производства к проектированию тоже бывали вопросы. К отделу продаж, зачастую, нет.

«Да появилось первое слово…а за ним хаос»
(с) спонтанная мысль автора

Ну и в завершение отметим блок «Начальство», которое не любило (да и сейчас не любит) работать в какой-либо системе. Да и зачем? Ведь у всех можно спросить всё «На словах»:

Вот так выглядела схема «AS-IS» (как есть). Далее мы разберём реализацию каждого способа коммуникации между отделами через ПланФикс.

 

Клиенты < — >Отдел продаж
Уходим от AmoCRM

Первая вещь – чтобы все заявки падали НЕ в AmoCRM, а в аккаунт ПланФикса. Когда мы внедряли AmoCRM, мы к работе прямо привлекали программиста, чтобы он все заявки с сайта заводил автоматически в AmoCRM+ ставил нужные значения в нужные поля. В случае с ПланФиксом – всё можно сделать самому и бесплатно.

Основной раздел для этих вещей – это Виртуальные почтовые адреса. Идея в том, что мы все-все обращения (кроме прямых звонков) отправляем на специальную почту ПланФикса. И уже в системе потом создаём нужные нам правила на обработку этих писем:

«Нууууу, так почту можно и в AmoCRM подцепить» – можете сказать вы.
ДА! Можно. Но вот настроить такие хитроумные правила обработки писем «из коробки» без программиста уже нельзя:

Первая вещь – проставление нужного значения в нужное поле. Вторая – удаление ненужного контента в письме (порой длинные письма неудобно закидывать как сделку в ПланФикс).

Сделали на каждый вид заявки своё правило – и радуйтесь.

 

А как же прямые звонки?
У ПланФикса есть целый набор интеграций с виртуальными АТС. Мы подключали клиента к Билайну.
Настройка предельно простая с разными возможностями «что делать в момент звонка»:

А вообще, советуем изучить полный набор интеграций, он просто огромен:

По звонку в нужном проекте создаётся сделка с нужными полями. И об этом уведомляется нужный человек. Всё понятно и просто.

Коммуникация с клиентом ведётся в такой же манере – изнутри сделки. Только в ПланФиксе нет отдельного понятия «написать письмо». Там любое действие в ленте – это «комментарий».

• Комментарий, о котором никто не уведомлён – это комментарий самому себе. Как заметка.
• Комментарий, о котором уведомлён сотрудник компании (у него есть аккаунт в системе) – это внутренний чат
• Комментарий, о котором уведомлён внешний человек (у него нет аккаунта в системе) – это отправленное письмо.

К этому обычно не сразу привыкают при переходе с другой CRM. Но привыкают.

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

Более подробно рабочий интерфейс отдела продаж разберём в отдельной следующей статье. Это уже немного «внутренняя кухня» блока «Отдел продаж».

Что-ж, начало положено. Первый этап коммуникации заведён в новую систему:

 

Отдел продаж < — > Отдел проектирования
Частично уходим от локальной сети

Почему частично?
Потому что всю-всю работу отдела проектирования мы НЕ заводили в ПланФикс (можно, но не на данном этапе). Главное – завести процесс передачи информации между отделами. А внутренняя работа каждого отдела – их забота. Так вот отделу проектирования для своих нужд было удобно хранить все-все-все локальные файлы (дизайны, чертежи и пр) в локальной сети. И заносить в систему лишь финальные варианты.

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

1) в нужный момент времени (когда есть все данные для расчётов), отдел продаж в нужные поля сделки добавляет сводную информацию по расчётам:

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

2) жмут кнопку «Отправить на расчёты». Ну…у нас она чуток по-другому называется 🙂 Но суть от этого не меняется:

 

3) В специально-настроенном планировщике методом «взял-перетащил» перетаскивают сделку в нужный приоритет расчёта (от 1 до 5)

ИЛИ не перетаскивают, если все приоритеты уже заняты. Все такие сделки висят в списке «Приоритет – прочее (только в очереди)» (крайний справа на картинке выше).

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

А планировщик – это лишь набор фильтров, которые можно отобразить в виде канбан-доски. Каждый столбец – это фильтр, который вытаскивает только задачи с нужным приоритетом:

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

4) Когда у проектировщиков появляется возможность взять новую сделку на расчёты, они заходят в этот же планировщик, заходят в сделку, которую хотят взять, и жмут на кнопку «Беру расчёт в работу»:

После этого сделка уходит из списка с приоритетами и появляется в списке «В процессе расчёта» (который так же видят отдел продаж и проектировщики):

К слову…этот планировщик довольно широкий и скролится вправо, чтобы видеть сделки в том или ином статусе:

Напомню – всё это отображение данных было настроено самостоятельно и с полного нуля. Можно сделать, как хотите. Лишь бы знали, куда тыкнуть 🙂

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

Этой информации вам вряд ли хватит для 100% понимания, КАК это сделать самим, но наша цель – дать как раз общее понимание «так можно» + направить на нужные страницы в справке системы. А там дальше сами разберётесь.

Кстати, этот планировщик у нас назывался «Сделки на расчёты». И он был доступен всем нужным людям, чтобы не на словах спрашивать, а всё видеть в системе.

И именно это теперь можно указать в нашей схеме:

Не смотрится тут стрелка от личных продаж директора в сторону отдела проектирования, да? Вроде наводим порядок, а этот треш ещё тут. Поэтому мы и это исправили.

Как?
«На словах» – тут как раз-таки этот метод пришёлся к месту. Просто обосновали, что давайте все работать «по уму» и абсолютно ВСЕ сделки заводить сначала в отдел продаж (в систему), а затем прогонять их по статусам. Чтобы не было прямых задач по новым сделкам в сторону отдела проектирования. Все поняли. Исправились 🙂

Это к тому, что не всё в компании исправляется какими-то навороченными системами. Порой «На словах» решает. Или даже так 🙂 :

В итоге стало так:

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

 

Бухгалтерия — >Отдел продаж
Храним всю информацию в одном месте

Дальше надо решить вопрос с «напрягами» со стороны бухгалтерии, пока отдел продаж не поубивал там всех. На схеме даже стрелка односторонняя – всегда были вопросы ОТ бухгалтерии. От отдела продаж вопросов к бухгалтерии не было ).

В решении этого пункта нам отлично помогли такие сущности ПланФикса, как «справочник». Это очень удобная и невероятно многофункциональная вещь. Ну а нам понадобился лишь самый очевидный функционал, а именно:

1. Хранение информации в нужной нам структуре
2. Предоставление доступа туда нужным людям

Мы добавили несколько справочников в систему:

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

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

Любое поле редактируется по клику. Отмечу недавнее нововведение ПланФикса – это тип поля «карта». Как видно выше, можно сразу наблюдать геоточку, указанную в этом поле. Удобно!

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

…при клике на которое мы «падаем» в справочник этого приложения:

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

В завершение отмечу, что очень удобно потом можно настроить права доступа к справочникам:

О, вспомнил. Таким же образом мы имеем в справочнике ссылку и на сам контакт:

При клике на него мы попадаем в карточку со всей доп. информацией – номера, телефоны, почты, другие люди. Всё, что «доктор прописал» 🙂

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

Да будет мир между отделами в компании! Схема стала выглядеть так:

 

Начальство < — > Отдел продаж
Визуализируем воронку продаж

Конечно, удобно, когда можно зайти в кабинет отдела продаж и спросить: «Так, как у нас успехи по сделкам?». Сразу дадут ответ…такой…абстрактный, на память.

А мы за точность. Поэтому для таких ситуаций мы создали отдельный планировщик под названием «Задачи отдела продаж», в котором визуализировали все статусы сделок в виде столбиков \ карточек с разным цветом. Просто почти каждый статус у нас имеет свой цвет, который можно задавать самому. Получилось так:

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

Пользовалось ли этим функционалом начальство – отдельная тема. Ну об этом в конце.
Схема стала такой:

 

Разные отделы < — > Производство
Отчёты – наше всё

В компании есть ежедневные планёрки по производству, где обсуждаются самые разные вопросы по части всего производства. И это правильно – личное общение между людьми обязательно должно быть. И не получится вытащить в систему решение ВСЕХ вопросов. НО мы можем вытащить туда часть, и довольно интересную – прогресс по любому заказу, да ещё и в деталях.

Это мы реализовали с помощью 2-х вещей:
1. Задач, где люди с производства отмечают результат в течение дня по тому или иному элементу фасадного декора
2. Отчётов, которые тянут данные из этих задач

п.1 мы здесь обсуждать не будем, т.к. он больше про «внутреннюю кухню» производства, а мы здесь больше говорим про «вещи внешние» (взаимодействие между отделами). Но эти детали мы разберём в какой-нибудь отдельной статье.

А отчёты – очень функциональная и простая вещь. Построение отчёта, в основном, сводится сначала к выбору полей, которые (и откуда) нужно показывать:

…а потом к выбору фильтров, по которым нужно отбирать задачи с этой информацией:

И потом «вуаля» – можно смотреть прогресс по каждому проекту, заявке и даже конкретному элементу декора:

Главное – заносить данные в систему оперативно, раз в день. А лучше – в момент совершения «операции» с элементом. О том, как мы придумали схему моментального занесения данных в ПланФикс через стороннее мобильное приложение – в отдельной статье.

И если все будут грамотно заносить данные, то у всех (начальство «высшее», начальство обычное, отдел продаж) будет возможность самостоятельно мониторить прогресс по любой заявке. Однозначно – удобно!

Схема стала такой:

 

Начальство < — > Бухгалтерия
Да те же справочники

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

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

Теперь мы имеем полную картинку:

Хотя…на самом деле…не всё так идеально. Видите, в блок «Начальство» входят все стрелочки? Мол, с начальством тоже общаются же. И по текущей (типа идеальной схеме) всё общение идёт в системе. Но, увы, нет. Например, по части начальства все входящие обращения идут так же «На словах». Потому что начальство ещё не выработало привычку работать с системой. Это вообще боль всех внедренцев – пересадить в систему само начальство.

«Хотим, чтобы все другие работали в системе, а я – по желанию»

Так можно…но неудобства будут. Но это уже выбор каждого (у начальства всё же есть выбор, как работать 🙂 ).

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

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

• Тарифы
• Виртуальные почтовые адреса
• Полный набор интеграций
• Кастомные поля
• Адреса
• Кнопки
• Планировщик
• Справочник
• Права доступа к справочникам
• Отчёты

P.S. А если вы хотите прочитать художественную версию внедрения ПланФикса для нашего клиента, то это можно сделать здесь.

Сергей Улаев

Руководитель ООО “ЭффКонтекст”

 

 

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