gifts2017

Как организовать прогнозирование пробега автомобилей и приглашение на техническое обслуживание в Альфа-Авто

Опубликовал Maxim Maxim (miavolas) в раздел Управление - Бизнес-процессы

В данной публикации рассмотрим как на базе типового отраслевого решения Альфа-Авто организовать приглашение клиентов на периодическое техническое обслуживание (далее - "ТО") автомобилей с использованием расчетных данных о прогнозируемом пробеге. Основной идеей статьи является необходимость работы со всей клиентской базой (и их автомобилей) предприятия. Ниже будет описание того как нужно организовать процесс.

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

Оттолкнувшись от задачи привлечения клиентов на регулярное техническое обслуживания можно разбить взаимоотношения с владельцами автомобилей на следующие составляющие:

  • Регистрация данных о владении автомобилем. Происходит, как правило, в момент продажи автомобиля либо обращения в сервис, а в общем случае это попадание в поле зрения организации клиента как владельца автомобиля;
  • Расчет – прогнозирование даты очередного обслуживания
  • Приглашение и запись на ремонт (корректировка данных о владении автомобилем, актуальности контактной информации, фиксация факта проведения ремонта на стороне);
  • Сам процесс выполнения регулярного ТО, так чтобы проще всего можно было прогнозировать пробег и дату следующего обслуживания.

Сам по себе процесс регулярного обслуживания носит циклический характер, что более наглядно выглядело бы так:

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

Это позволит в каждом документе на техническое обслуживание установить прогнозное значение даты следующего ремонта простым добавлением межсервисного интервала к текущим данным

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

Также при работе с документом на обслуживание осуществляется регистрация пробега автомобиля

Рис пробеги

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

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

Про регистрацию данных о владении автомобилем:

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

рис Характеристики автомобилей

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

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

Справочники.Автомобили.ЗаписьЗначенияРегистраСведения(Автомобиль, Заказчик, Перечисления.ДополнительнаяИнформацияАвтомобилей.Хозяин);

Не менее важно в информационной системе отражать данные о том, что автомобиль не принадлежит более старому владельцу. Чаще всего данная ситуация выявляется в процессе приглашения по телефону, когда клиент сообщает, что автомобиль ему более не принадлежит(подробнее рассмотрим это при описании этапа приглашения клиента на ремонт).

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

В типовом отраслевом решении - Альфа-Авто 5ой версии для расчета плановых дат технического обслуживания предназначены 2 отчета:

Первый отчет - "Скорость пробега автомобилей" работает, используя данные регистра сведений "Характеристики автомобилей", которых самих по себе явно недостаточно для планирования даты технического обслуживания. Важно, что построение отчета происходит из предположения, что обслуживание автомобиля должно происходить на пробеге кратном межсервисному интервалу, например 15 000 тыс км, 30 000 км и т.д., А на самом деле это лишь межсервисный интервал, который при прохождении очередного ТО должен прибавляться к пробегу. 

Так например, если автомобиль проходил техническое обслуживание на пробеге 14 000 км, то следующее ТО необходимо проводить на пробеге 29 000 тыс км, а не 30 000 тыс

Второй отчет типового отраслевого решения "Анализ пробега автомобилей" является более развитым инструментом.

рис шапка отчета анализ пробега автомобилей

Механизм получения данных отчета следующий:

1) получаем таблицу минимальных и максимальных значений пробега с датами, на которые зафиксированы данные показатели;

2) получаем данные о последних заказ-нарядах с видом ремонта: Техобслуживание за период формирования отчета;

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

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

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

Однако не так все гладко. Сам по себе отчет не является инструментом для организации «обзвона» выборки клиентов. Для этого чтобы систематизировать обработку списка контрагентов целесообразно использовать специализированный - документ Рассылка с видом операции «Телемаркетинг», заполнение которого данными отчета в типовом решении на момент написания публикации отсутствовало.

Документ Рассылка позволяет зафиксировать список контрагентов, а для упорядочивания самого общения дальнейшее приглашение используется документ Опрос. Оба этих документа относятся к подсистеме «Учета взаимоотношений с клиентами»

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

- вопросы, которые отражали бы этап подготовки к звонку;

- собственно сами вопросы, задаваемые клиенту;

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

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

О подготовке к звонку:

Очевидна необходимость до начала общения с клиентом определиться со стоимостью предлагаемого обслуживания, что нашло свое отражение в вопросе под названием «Предложенная клиенту сумму ТО»

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

О вопросах которые нужно задать клиенту:

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

В результате в форме списка наблюдаем новую связку новую связку Владелец – Автомобиль как на рисунке ниже

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

О фиксации результатов общения:

По завершении общения с потенциальным клиентом важно зафиксировать как положительный, так и отрицательный ответ. И если результатом согласия клиента на ремонт, может являться как ссылка на документ «Заявка на ремонт» с определенным временем записи или запланированный контакт для уточнения времени визита. То при отказе важно зафиксировать не только сам факт, но и выявить причину отказа (вопрос «Причины отказов..» анкеты). Классифицируя причины отказов нужно разделять: принципиальный отказ от дальнейшего обслуживания и нежелание (отсутствие возможности) клиента именно в этот раз получить обслуживание в нашей организации.

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

Для анализа результатов анкетирования в конфигурации присутствует одноименный отчет ("Анализ результатов анкетирования") который к сожалению не обладает гибкостью настроек остальных отчетов. Однако может быть изменен, например как это описано в публикации http://infostart.ru/public/513622/

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Андрей Камынин (AndrewK990) 24.06.16 15:17
Добрый день, мы также используем Альфа-Авто и не единожды пытались организовать маркетинговые мероприятия для приглашения клиентов на первое ТО, обязав мастеров приемщиков пригласить тех клиентов которые были у каждого из них в прошлом году, однако так и не смогли отследить результативность этого мероприятия.
Назрело 2 организационных вопроса:
1. Удалось ли привлечь доп. клиентов уже или все еще только внедряется?
2. Как оператор узнает что для определенного клиента сработал прогноз и его следует пригласить на ТО, работает какая -то система оповещения? (что-то вроде подсказки или всплывающего окна - "через 5 дней планируется запись на ТО для такого-то такого-то")?
2. Maxim Maxim (miavolas) 25.06.16 16:06
(1) AndrewK990, конечно описываемая методика, которая используется не на одном предприятии позволяет привлечь дополнительных клиентов. Но оценивая количество привлеченных клиентов надо самим понимать, что сформировав отчет с цифрами положительных ответов, мы никогда так и не узнаем сколько из них в момент звонка отказались от визита, а позже все равно приехали. Так же как некоторые из клиентов приехали бы и без нашего звонка :)
В описываемой системе не используется механизм напоминаний, но это не потому что его никогда не было :) практика работы реальных клиентов показала, что пользователь будучи не выделенным только для звонков по телефону специалистом напоминание откладывает, и не факт что реально к нему вернется. А если речь идет о выделенных для проведения обзвонов специалистах call-центра, то им напоминания не нужны, ведь они по списку клиентов совершают звонки.
dj_serega; AndrewK990; maxim1c; +3 Ответить 1
3. Maxim Maxim (miavolas) 25.06.16 16:09
Хотя вместо рассказа о напоминаниях можно было бы описать похожую систему, которую делали с использованием механизма бизнес-процессов платформы 1с
самая простая реализация вообще была линейная

Но при использовании бизнес-процессов так и не получилось корректно отразить ситуацию с изменением документов задним числом, которое встречается в реальной жизни
4. Вадим Купинов (izofen) 25.06.16 16:20
Документ опрос, только фиксирует ответы на вопросы или есть программная обработка результатов ответа?
5. Дарья Чернышова (chernyshova_darya) 26.06.16 16:23
(4) izofen, у меня близкий к вашему вопрос, действительно интересно, ну ответил посетитель автосервиса, что сейчас какой то там пробег его автомобиля и он отличается от того который в вашей базе , и что?
6. Maxim Maxim (miavolas) 27.06.16 07:18
(4) izofen, (5) chernyshova_darya, в документе опрос, может существовать программная обработка ответов.... так будучи "завершенным" документ, при записи фиксирует: пробег автомобиля ; запись о владении автомобилем (либо подтверждение владения, либо запись о том что автомобиль более не принадлежит владельцу), фиксирует новую дату актуальности контактной информации.
7. Игорь Попков (pim56) 28.06.16 05:41
Мы используем смс информирование для приглашения клиентов однако замечаем что количество клиентов для приглашения становится все меньше и меньше, но детального анализа с чем связано это уменьшение пока не проводили
8. Maxim Maxim (miavolas) 28.06.16 07:42
(7) pim56, если вы используете только типовой функционал, то причиной уменьшения выборки клиентов может быть не только отток покупателей, но еще и различные технические вопросы самой конфигурации.. так например, если клиент не приедет однажды на техническое обслуживание, то уже на следующий раз он не попадет в выборку предлагаемую отчетом "Анализ пробега автомобилей", также можно столкнуться с необходимостью фиксировать пробег новых автомобилей, перед реализацией для повышения точности расчета(ведь при продаже в типовом решении не устанавливается).
Что же использования смс к сожалению не позволяет получить обратную связь, а получить представление насколько удачно используется приглашение клиента сложно даже при построении процесса с обратной связью в виде ответов клиентов по телефону.
9. Гарик Гариков (Гарик55555) 28.06.16 08:13
Хорошая статья. Я только не понял это отдельная конфигурация или доп. обработка?
10. Maxim Maxim (miavolas) 28.06.16 08:18
(9) Гарик55555, это описание методики работы с типовым функционалом отраслевой конфигурации Альфа-Авто, при наличии очень ограниченной информации которая идет в поставке, не сразу получилось запустить процесс.. делимся своим опытом
11. Вадим Купинов (vikupinov) 28.06.16 08:54
(3) miavolas, Очень интересно было бы посмотреть на реализацию приглашения клиентов в виде бизнес-процесса. Думаю что такой бизнес-процесс нашел бы большое применение не только в Альфа-Авто, но и в типовых конфигурациях
12. Maxim Maxim (miavolas) 28.06.16 09:06
(11) vikupinov, реализация бизнес-процесса не является секретом, но учитывая, то что фрагменты кода включены в различные объекты метаданных, не знаю какая часть вас особенно заинтересовала бы.. могу отправить на почту
13. Димок ддд (ДимокШ) 30.06.16 13:11
Пришлось переделывать типовую или нет?
14. Maxim Maxim (miavolas) 30.06.16 13:39
(13) ДимокШ, данная публикация описывает использование типового отраслевого решения, как его можно было бы использовать без внесения изменений и касается в основном методической части. Обозначенные вопросы :
- о фиксации нулевого пробега автомобиля, если на момент продажи не зарегистрированы показатели одометра;
- регистрации данных о владении автомобилем в процессе опроса клиента по телефону;
- регистрации примерного значения последнего пробега со слов клиента
- регистрации данных о прохождении ТО в другом месте
- о возможности контролировать полноту клиентской базы для приглашения на обслуживание
имеют большое значение для прогнозирования и не единожды решались внесением изменений в типовые конфигурации заказчиков. Но это отдельная тема для разговора и будет опубликована позже
15. Евгений Моисеенко (bpc222) 22.07.16 08:20
(1) AndrewK990,

обязав мастеров приемщиков пригласить тех клиентов которые были у каждого из них в прошлом году, однако так и не смогли отследить результативность этого мероприятия


Явная проблема со SMART при постановке задач...
16. Артем Трущ (papami) 26.07.16 20:47
(2) miavolas, поставил + за то что делитесь опытом.
Сам достаточно давно участвую в автоматизации автобизнеса, в том числе есть холдинг, где все основные действия расписали по бизнес-процессам в 1С.
Для тех кто начинает:
1. Нужны не напоминания, а задачи с исполнителями и максимальными сроками выполнения.
2. Опишите в виде бизнес-процессов работу отделов:
а) Сервис - "Выполнение ремонта"(от приезда автомобиля и до выдачи). Это основная функция сервиса - она будет упорядочена. Будет меньше "косяков"
б) Продажи - "Визиты клиентов в салон". Упорядочиваем трафик и "мотивируем" продавцов вбивать данные о клиентах.

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

3. Задачи, связанные со звонками нужно интегрировать с системой записи. Т.к. не всегда та информация, что указана в телефонной анкете соответствует словам клиента. Могли вообще не звонить.
4. Задачи, связанные с созданием каких либо документов желательно закрывать автоматически с указанием исполнителя. Если есть возможность избавить персонал от лишних действий - нужно избавлять.
5. Все задачи нужно анализировать отчетами, в том числе принимать меры при несвоевременном выполнении

miavolas; trader7777777; +2 Ответить 2
17. Maxim Maxim (miavolas) 27.07.16 09:17
(16) papami, спасибо большое за столь дельный комментарий. Изначально данная публикацию планировалось в двух частях... 1-ая описывает типовой функционал и 2-ая рассказывает про доработки, К сожалению я недооценил время которое потребуется для написания статьи поэтому пока опубликована лишь первая часть которая описывает методику использования того что есть....
Очень интересна ваша практика использования бизнес-процессов и инструментов для управления ими.
Очевидные плюсы от использования бизнес-процессов как механизма платформы могут быть сведены на нет отсутствием удобного инструмента для их анализа и управления ими. Существующие CRM-решения позволяют не изобретать велосипед



Особенно интересно как коллеги решают задачу нехватки инструментов управления задачами и бизнес-процессами во отраслевых конфигурациях?
18. Трейдер Трейдерович (trader7777777) 27.07.16 10:42
(16) papami, понравился ваш комментарий.. вы пишете:
"Задачи, связанные с созданием каких либо документов желательно закрывать автоматически с указанием исполнителя. Если есть возможность избавить персонал от лишних действий - нужно избавлять"
Интересно есть наработки как можно было бы отразить в бизнес процессе отмену проведения или пометку удаления документа?
Мы так понимаем что вы говорите об автоматическом выполнении задачи (очередного этапа бизнес-процесса) при проведении документа.
Интересно был ли опыт отработки проведения / перепроведения документов задним числом (например при восстановлении последовательностей) , что в таком случае должно происходить с бизнес процессом?
19. Артем Трущ (papami) 27.07.16 14:04
(17) miavolas, Альфа - неплохая база для развития, не более. Она оптимальна для учета в автобизнесе, но уже из коробки не соответствует требованиям вендоров в плане CRM (JLR, VAG. Думаю подобная ситуация у большинства представительств). По другим отраслевым решениям не решусь давать оценку.
Да, написать понятную статью - большой труд. Мне не дано, видимо)

(18) trader7777777, не знаю Вы программист или управленец. Если в общих словах, то связь документа с выполнением какой-либо задачи следует выполнять только в интерактивном режиме, т.е. когда документ проводит пользователь. Точнее "Процедура ПослеЗаписи()". Восстановление последовательностей не повлияют на бизнес-процесс.
20. Maxim Maxim (miavolas) 24.08.16 09:48
(3) miavolas, в продолжение поста возможна и нелинейная структура как на картинке
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа