Введение
Тенденция цифровизации стремительно захватывает все больше областей функционирования бизнеса, повышая обоснованность принятия управленческих решений и приводя к кардинальным изменениям бизнес-процессов [1]. Современные компании активно внедряют передовые технологии для автоматизации процессов, повышения эффективности и конкурентоспособности. Одной из ключевых задач цифровой трансформации становится обеспечение интеграции различных информационных систем, платформ и сервисов [2, 3]. Крупные автопроизводители, имеющие разветвленные сети дилерских центров, стремятся организовать автоматизированный централизованный контроль эффективности деятельности каждого из них и выстраивают целые цифровые экосистемы с обширным спектром функциональных возможностей составляющих их модулей [4, 5]. При этом возникает потребность настройки интеграционного взаимодействия и информационного обмена данными между используемыми в дилерских центрах учетными системами и внедряемыми автопроизводителем системами управления дилерской сетью и взаимоотношениями с клиентами. К числу таких компаний относится АО «АвтоВАЗ», имеющее одну из самых крупных дилерских сетей на территории Российской Федерации [6, 7]. Компания демонстрирует устойчивую тенденцию роста и активно развивает дилерскую сеть: на октябрь 2024 г. под контролем компании функционирует 333 официальных дилерских центра, прирост к 2021 г. составляет 9,3 %. Все участники дилерской сети LADA реализуют автомобили LADA на территории Российской Федерации и обеспечивают полный цикл их обслуживания (гарантийный, коммерческий ремонт, техническое обслуживание) на протяжении всего периода эксплуатации транспортного средства. Работают они в соответствии с международными стандартами и в глобальном рейтинге дилерских сетей по клиентскому сервису, пред- и послепродажному обслуживанию занимают достаточно высокие позиции. Наряду с политикой единства цен в дилерской сети используется единый фирменный стиль и реализуется строгий корпоративный стандарт сбытовой деятельности, взаимодействия и уровню обслуживания клиентов. Исследование тенденций развития управления дилерскими сетями показало, что ключевыми направлениями его совершенствования являются [4, 7, 8]:
– процессы диджитализации всех аспектов взаимодействия с клиентами бренда и стремление перехода к омниканальной модели организации продаж и обслуживания;
– выстраивание глубоко персонализированного клиентского сервиса, повышение удовлетворенности и формирование сверхрелевантного клиентского опыта, предполагающего полное соответствие клиентским ожиданиям и запросам, повышение удовлетворенности и лояльности к бренду;
– увеличение уровня доверия клиентов к бренду посредством обеспечения прозрачности и открытости всех этапов взаимодействия с дилерским центром и автопроизводителем.
В современных условиях эффективная организация системы управления дилерской сетью невозможна без соответствующего информационно-технологического обеспечения. Для управления сетью дилерских центров автопроизводители используют различные специализированные программные продукты, веб-ресурсы, платформы и сервисы. Такая структура цифровых экосистем управления дилерскими сетями позволяет обеспечить соответствие направлений развития дилерской сети выделенным тенденциям. В 2023 г. для централизованного автоматизированного управления дилерской сетью и взаимоотношениями с клиентами компания АО «АвтоВАЗ» приняла решение о внедрении системы управления дилерской сетью, предъявив дилерским центрам требование настройки интеграционного взаимодействия используемых ими учетных систем с системой управления автопроизводителя, где в единой экосистеме реализовано управление данными о состоянии запасов, продаж, сбытовой деятельности и сервисного обслуживания клиентов по всем дилерским центрам. Система управления дилерской сетью АО «АвтоВАЗ» включает несколько укрупненных модулей (рис. 1). Встроенные аналитические инструменты системы позволяют генерировать отчетную информацию, осуществлять мониторинг ключевых показателей эффективности сбытовой деятельности (KPI) дилерских центров в режиме реального времени и на основе результатов проведенного анализа принимать обоснованные управленческие решения. Каждый из модулей предполагает автоматизацию укрупненной группы процессов взаимодействия с клиентами и информационного обмена между дилерскими центрами и автопроизводителем. Полная информационная база данных дилерских центров с соответствующими инструментами контроля деятельности каждого из них находится в модуле управления стандартами дилерской сети. Несколько крупных модулей отведено для автоматизации управления взаимоотношениями с клиентами бренда LADA.
Рис. 1. Основные модули DNM-системы АВТОВАЗ Источник: составлено авторами
Модуль «Клиенты и коммуникация» предназначен для хранения полной структурированной информации о клиентах бренда на каждом этапе жизненного цикла взаимодействия с дилерским центром, включая всю историю взаимодействия. В отдельном модуле хранится база в разрезе сервисного обслуживания клиентов и их транспортных средств. По каждому дилерскому центру в модуле представлена база заказ-нарядов, информация по работе с претензиями и повторными обращениями в целях проведения сервисных работ. Каждый из этих модулей формирует агрегированные отчеты с возможностью сегментации клиентской базы в зависимости от условий отбора. Модули «Клиентский и дилерский маркетинг» и «Удовлетворенность клиентов» предназначены для планирования и реализации маркетинговых активностей, а также анализа удовлетворенности клиентов уровнем обслуживания. Система управления дилерской сетью содержит полный набор инструментов для управления и оперативного контроля продаж дилерских центров. Помимо модуля складского учета автомобилей, предполагающего интеграцию с дилерскими автоматизированными системами, она содержит «живую» воронку продаж с полностью автоматизированным процессом сбора данных по всем клиентам, событиям и активностям, онлайн-витрину и различные формы, обеспечивающие ИТ-сопровождение и поддержку онлайн-продаж (страховой и кредитный калькуляторы, калькулятор технического обслуживания, онлайн-оценка транспортного средства и интеграция с сервисами онлайн-оплаты и e-commerce).
Таким образом, по результатам анализа функциональных возможностей модулей DNM-системы можно сделать вывод о том, что внедрение единой платформы позволит компании не только осуществлять централизованное управление дилерской сетью и контролировать соблюдение стандартов бренда. АО «АвтоВАЗ» получит возможность координировать взаимодействие между дилером и автопроизводителем и обеспечить единый уровень обслуживания клиентов бренда в рамках всей дилерской сети. Поэтому компания АО «АвтоВАЗ» жестко регламентировала обязательные параметры настройки интеграции используемых в дилерских центрах учетных систем с централизованными сервисами и системами автопроизводителя. При этом настройка интеграционного взаимодействия учетных систем дилерских центров с DNM-системой должна реализовываться поэтапно. В рамках настоящего исследования решена задача разработки интеграционного модуля взаимодействия учетной системы одного из дилерских центров компании АО «АвтоВАЗ» с модулем «Продажи» системы управления дилерской сетью автопроизводителя.
Цель исследования состоит в разработке на платформе «1С: Предприятие» интеграционного модуля для синхронизации и обмена данными между отраслевой конфигурацией «1С: Альфа-Авто» и системой управления дилерской сетью АО «АвтоВАЗ» в части реализации требований автопроизводителя по передаче дилерскими центрами данных по продажам автомобилей.
Материалы и методы исследования
Предпроектное обследование предметной автоматизации включало авторское исследование и анализ информационного поля с результатами практических и теоретических исследований по следующей проблематике. Авторами проведен анализ современных трендов мирового и российского автомобилестроения [1, 5]. Изучены особенности организации и функционирования дилерских сетей крупных автопроизводителей, прежде всего с точки зрения их информационно-технологического обеспечения, тенденций развития управления дилерскими сетями, функциональные возможности и потенциальные эффекты внедрения автопроизводителями современных цифровых онлайн-сервисов и платформ как ключевых элементов цифровых экосистем управления дилерскими сетями и организации взаимодействия с клиентами бренда [4, 7, 8]. Установлено, что для их эффективного использования и централизованных коммуникаций дилерских центров с производителями возникает потребность настройки интеграционного взаимодействия и информационного обмена данными между используемыми в дилерских центрах корпоративными системами и внедряемыми автопроизводителем системами управления дилерской сетью. Далее было проведено моделирование реализации типового бизнес-процесса организации предпродажной работы с клиентами дилерского центра, идентифицированы ключевые элементы его документационного сопровождения и их отражение в учетной системе дилера, а также выделены «узкие места» реализации, не позволяющие автопроизводителю осуществлять оперативный контроль процесса продажи транспортных средств и качества ведения каждой сделки. На основе выявленных недостатков и анализа требований к интеграции и формату обмена данными были разработаны функциональные требования к разрабатываемому интеграционному модулю.
Следующим этапом стало изучение способов интеграции информационных систем [2, 3], а также механизмов технологической платформы «1С: Предприятие» с точки зрения возможных вариантов реализации интеграционного взаимодействия. При этом особое внимание уделено исследованию вариантов обмена данными типовой конфигурации с внешними ресурсами и приложениями [9, 10]. Проведен анализ способов синхронизации данных учетной системы и веб-сервиса [11, 12], а также регламентирующей документации по их эффективному и рациональному использованию. По результатам исследования спроектирована иерархическая структура метаданных интеграционного модуля конфигурации и осуществлена ее реализация.
Результаты исследования и их обсуждение
По результатам анализа предметной области установлено, что ключевым элементом стратегии автопроизводителя является развитие взаимоотношений с клиентами бренда. В соответствии с этим все бизнес-процессы дилерского центра выстраиваются на основе концепции клиентоцентричности. Для дилерского центра одним из наиболее важных этапов управления продажами автомобилей является предпродажное взаимодействие с потенциальными покупателями и клиентами. Грамотно выстроенная работа с клиентом с большой долей вероятности гарантирует успешное совершение сделки, способствует росту клиентской базы, индекса удовлетворенности обслуживанием и лояльности к дилеру. Проведенные исследования показали, что процесс обслуживания клиентов в дилерском центре представляет собой их поэтапное двунаправленное взаимодействие. Декомпозиция типового бизнес-процесса продажи автомобиля на этапы его реализации позволяет, наряду с непосредственной предпродажной подготовкой самого транспортного средства (ТС), выделить целый комплекс работ, направленных именно на предпродажное взаимодействие с клиентом:
– первичный контакт с клиентом (обработка телефонного звонка, общение во время очного визита в дилерский центр, ответ на электронное письмо или обработка заполненной клиентом формы на сайте) в целях выявления его потребностей и ожиданий;
– планирование дальнейшего взаимодействия;
– презентация предложений дилерского центра на основании анализа запроса клиента;
– подбор, конфигурирование и резервирование автомобиля;
– дополнительное информирование клиента о маркетинговых акциях и системе скидок;
– планирование и организация тест-драйва;
– подготовка коммерческого предложения;
– заказ автомобиля у поставщика;
– заключение договора и отгрузка автомобиля.
Организация большей части выделенных работ входит в должностные обязанности менеджеров дилерских центров. Очень важно тщательно отслеживать все действия клиента. Анализ этих данных впоследствии позволяет выделить, через какие источники клиенты находят информацию и обращаются в дилерский центр, определить, какая модель автомобиля вызывает больший интерес, насколько часто контакт клиента с дилерским центром завершается подписанием контракта и собственно продажей автомобиля, составить статистику продаж и т.д. Сбор и анализ этих данных необходим как инструмент повышения продаж автомобилей, обеспечения соответствия требованиям со стороны автопроизводителя и установления более выгодных и надежных отношений с компанией АО «АвтоВАЗ». Автопроизводитель аккумулирует информацию от дилерских центров и контролирует необходимые показатели: статистику продаж каждого дилера, его активность в регионе и за пределами и др. Это позволяет понять, какие модели чаще всего продаются, какие дополнительные опции чаще всего клиенты приобретают и, самое главное, через какие дилерские центры проходит больше всего продаж.
Как правило, предпродажная работа с клиентом дилерского центра фиксируется в документе «Рабочий лист» (РЛ), который позволяет отслеживать и контролировать все этапы продаж, начиная с первого контакта с клиентом и заканчивая отгрузкой автомобиля и завершением сделки. Документ хранит полный набор данных по всем взаимодействиям с клиентом, фиксируя все данные по первичным и изменяющимся потребностям каждого из них, способ обращения и способ приобретения, аккумулируя всю информацию по каждой сделке по принципу «одного окна».
В учетной системе дилера рабочий лист представляет собой электронную форму ввода, редактирования и хранения информации об этапах обработки обращений клиентов и возможной покупке автомобиля. В системе «1С: Альфа-Авто» РЛ является одним из основных объектов конфигурации, использующимся для управления процессом продажи ТС и организации учета взаимодействия с клиентом. В нем фиксируется следующая информация:
– данные по клиентам и потенциальным покупателям;
– сведения об автомобиле, который клиент хочет приобрести (потребность), включающая марку, модель, год выпуска, на поздних этапах за клиентом закрепляется конкретный автомобиль, вводится его VIN, госномер (если автомобиль с пробегом);
– способ привлечения клиента в дилерский центр («холодный» звонок, реклама и др.);
– параметры сделки (сумма сделки, способ оплаты и приобретения (наличными, в кредит, по программе Trade-in), ответственный за сделку менеджер.
В рабочем листе также фиксируется каждое событие, касающееся взаимодействия клиента с дилерским центром: производится планирование визитов, звонков, тест-драйва, временное резервирование транспортного средства за клиентом. В нем указывается вся информация о подготовке коммерческого предложения, заключении контракта на покупку автомобиля или же причины отказа от его приобретения. Документ содержит информацию о текущем статусе выполнения задач и этапов продаж, что позволяет осуществлять оперативный контроль процесса и своевременно реагировать на возникающие в нем изменения. Соблюдается хронологический порядок событий. С этой целью для каждого события предусмотрена возможность установки статуса: «Запланировано», «Завершено», «Отменено». В свою очередь, каждый рабочий лист имеет свои статусы: «Отказ», «Создан», «Интерес», «Продажа», «Сделка». В учетной системе «1С: Альфа-Авто» присутствуют встроенные отчеты, которые позволяют посмотреть статистику и провести анализ по множеству рабочих листов за определенный период. На основании отчетов проводится анализ как каждой совершенной сделки, так и по их совокупности за различные временные периоды, оценивается эффективность работы менеджеров, выявляются успешные стратегии и области, требующие корректирующих действий с точки зрения оптимизации и улучшения. АО «АвтоВАЗ» получает сводные данные дилерских центров по рабочим листам только в установленные им отчетные периоды. Отправку отчетов (за неделю, месяц, квартал, год) дилерский центр производит по электронной почте. Этот метод неэффективен, поскольку автопроизводитель не имеет возможности осуществлять оперативный контроль продажи транспортных средств и качества ведения каждой сделки (причины отказов, брошенные рабочие листы с отсутствующими активными событиями, отмены контрактов и т.д.), не может оценить работу менеджеров дилерских центров при взаимодействии с клиентом, провести анализ первичных потребностей клиентов, причины их изменения и невозможности удовлетворения в случае отказа от приобретения автомобиля.
После внедрения системы управления процессами дилерской сети АО «АвтоВАЗ» выдвинул требование по настройке ее интеграции с учетными системами дилерских центров. В рамках настоящего исследования была поставлена задача разработки интеграционного модуля, обеспечивающего обмен данными по продажам автомобилей и автоматическую передачу информации по рабочим листам из локальной системы дилерского центра в DNM-систему АВТОВАЗ. Требования к первичной настройке справочников системы управления дилерской сетью, формату обмена данными и составу получаемых из внешних систем данных были определены самим автопроизводителем и компанией-разработчиком ООО «ИНФОТЕК» (Россия). В соответствии с требованиями данные по рабочим листам, его событиям и активностям из учетной системы дилера должны передаваться как в режиме реального времени, так и один раз в день и автоматически вноситься в интерактивный рабочий лист DNM-системы. На основе результатов анализа и требований к настройке синхронизации и обмена данными с DNM-системой АВТОВАЗ были сформированы функциональные требования к интеграционному модулю и определены ключевые объекты конфигурации «1С: Альфа-Авто», добавление которых необходимо для обеспечения его функционирования (табл. 1).
Пользовательский интерфейс интеграционного модуля должен быть информативным, интуитивно понятным и простым для использования, содержать понятные инструкции и подсказки, поэтому требование F1 является первоочередным требованием разработки. Объекты, добавляемые согласно требованиям F2–F6, должны быть доступны как по отдельности, так и в общем интерфейсе доработки.
Таблица 1
Функциональные требования к интеграционному модулю
Идентификатор |
Формулировка |
Рекомендации по реализации требования |
Объект конфигурации / тип запроса |
F1 |
Все возможности системы должны быть доступны в одном месте |
По нажатию кнопки открывается форма интеграционного модуля |
Обработка «Binom_DNM_ОбменЛада» |
F2 |
Система должна хранить настройки для подключения к DNM |
По нажатию кнопки выбора открывается список настроек |
Справочник «DNM Настройки» |
F3 |
Система должна загружать информацию справочников из справочников DNM |
По нажатию кнопки «Синхронизировать» отправляется запрос в DNM-систему и происходит заполнение справочников в учетной системе дилера |
Справочники из таблицы Процедура «GET-запрос» |
F4 |
Система должна позволять сопоставление загруженных справочников и справочников системы |
По нажатию кнопки «Настройка» открываются справочники 1С «Альфа-Авто». Затем пользователь самостоятельно выбирает элементы, которые надо сопоставить с загруженными. |
Дополнительные реквизиты в справочниках учетной системы дилера |
F5 |
Система должна выгружать данные документа «Рабочий лист» в DNM |
Пользователь выбирает Рабочие листы, которые хочет отправить в DNM. По нажатию кнопки «Отправить РЛ в DNM» происходит выгрузка |
Процедура «POST-запрос» |
F6 |
Система должна обновлять статус выгруженных рабочих листов в DNM |
Пользователь может отправить Рабочий лист повторно, если в документ были внесены изменения. При этом новой записи в DNM создаваться не будет, а будет обновлена имеющаяся |
Процедура «PUT-запрос» |
Для требования F2 понадобится разделение доступа по ролям: доступ к настройкам подключения должны иметь только специально обученные сотрудники, так как изменение этих настроек напрямую влияет на функционирование интеграционного модуля. При просмотре сохраненных настроек Bearer-токен для авторизации в DNM не должен отображаться в пользовательском интерфейсе, так как это не отвечает требованиям безопасности. Важно, чтобы для пользователя было разделение по разделам функционала требований F3–F4 и F5–F6, так как предполагается раздельное их использование. Загрузка справочников и настройка соответствия будет осуществляться только в начале работы модуля и при внесении изменений на сервере DNM. Для требований F3–F4 необходимо создать новые объекты в учетной системе дилера. Пользователь должен иметь возможность просмотра этих объектов. Интерфейс для взаимодействия с ними должен содержать только важную информацию и должен быть легко читаем. Кнопки на основном окне интерфейса интеграционного модуля должны располагаться интуитивно понятно пользователю и иметь легко читаемые названия. Это справедливо также для требований F5–F6.
Важно, чтобы велась история ошибок с возможностью получения пользователем уведомления о ее наступлении. Предусмотрено ведение лога – формирование текстового файла, в который автоматически будет записываться информация о корректности работы системы/программы/модуля. При появлении ошибок при загрузке/выгрузке DNM будет передавать уникальный код ошибки. Эти данные будут записываться в текстовый документ, что позволит своевременно обнаруживать и устранять проблемы, связанные с программным кодом или же с некорректным использованием модуля.
На основе анализа функциональных требований был разработан поэтапный план реализации проекта интеграции:
1. Доработка учетной системы дилера (добавление новых объектов в типовую конфигурацию «1С: Альфа-Авто»).
2. Настройка подключения к DNM-системе АВТОВАЗ.
2.1. Настройка загрузки справочников из DNM-системы АВТОВАЗ в учетную систему дилера.
2.2. Настройка соответствия справочников DNM-системы и учетной системы дилера.
2.3. Настройка выгрузки рабочих листов из системы дилера в DNM-систему АВТОВАЗ.
3. Реализация выгрузки рабочих листов в тестовую DNM-систему.
3.1. Перенос интеграционного модуля в рабочую конфигурацию.
3.2. Реализация выгрузки рабочих листов в рабочую DNM.
3.3. Обучение сотрудников работе с интеграционным модулем и запуск его работы.
Если рассматривать взаимодействие дилера и компании ООО «ИНФОТЕК» в процессе реализации разработки, можно выделить следующие этапы: сначала дилерскому центру выдается токен для тестовой DNM и данные учетных записей для проверки переданных через интерфейс DNM данных. Дилер выполняет обязательные работы по настройке интеграции с тестовой DNM и проверяет настроенную интеграцию. На следующем этапе отправляются токен и учетные записи для рабочей DNM, реализуется и проверяется интеграционное взаимодействие с ней.
Рис. 2. Схема обмена данными между учетной системой дилера и DNM Источник: составлено авторами
Рис. 3. Алгоритм подключения и передачи данных в DNM по рабочим листам Источник: требования к формату обмена данными
В целях упрощения процесса интеграции с учетными системами дилеров, ООО «ИНФОТЕК» разработало для DNM собственный программный интерфейс API (Аpplication Programming Interface), содержащий набор прописанных методов, по которым будет происходить обращение из учетной системы дилера на сервер DNM. Подключение к DNM происходит по протоколу HTTPS. В отличие от протокола HTTP, при подключении требуется авторизация. Схема обмена данными 1С: Альфа Авто и сервером DNM-системы представлена на рис. 2.
Для авторизации в DNM используется Bearer-токен. Из учетной системы дилера отправляется запрос на получение данных или создание новой записи в DNM. Вместе с этим запросом отправляется уникальный Bearer-токен, предоставленный АО «АвтоВАЗ». Поскольку в разработке использовался API, в запросах прописаны методы, описанные в документации к API, чтобы система понимала, какие данные запрашиваются. В ответ сервер DNM отправляет в учетную систему дилеру запрашиваемые данные или же данные о созданной записи.
Перед реализацией функциональных требований был использован алгоритм, согласно которому интеграционный модуль должен будет работать и реализовать передачу данных рабочих листов в DNM-систему (рис. 3).
Для реализации проекта интеграции потребовалась доработка типовой отраслевой конфигурации «1С: Альфа-Авто», а именно – добавление новых справочников и новых реквизитов для существующих. Добавленные справочники должны отражать содержание справочников в DNM-системе. Полный список добавленных справочников представлен в табл. 2.
Для взаимодействия с модулем интеграции была создана обработка «Интеграция с DNM (обмен)», для хранения настроек подключения к DNM создан отдельный справочник «DNM Настройки». На управляемую форму обработки добавлены две страницы: для загрузки справочников из DNM и для выгрузки рабочих листов в DNM. Также на форму была добавлена возможность выбора настроек подключения к DNM (рис. 4).
Таблица 2
Список добавленных в типовую конфигурацию справочников
Наименование справочника |
Описание справочника |
DNM Алиасы Моделей_Model_alias |
Справочник алиасов моделей. Содержит развернутую информацию о модели авто |
DNM Бренды_Brand |
Справочник брендов автомобилей. Содержит наименование бренда, его код в DNM-системе, по которому будет происходить его передача |
DNM Модельные Года_Model_year |
Справочник модельных годов. Содержит год выпуска модели и код этого года в DNM-системе |
DNM Должности Сотрудников_Position |
Справочник должностей сотрудников. Содержит название должности и ее код в DNM-системе, по которому будет происходить ее передача |
DNM Список Сотрудников_Manager |
Справочник сотрудников. Содержит ФИО сотрудника и его код в DNM-системе, по которому будет происходить его передача |
DNM Источники Обращения_Source |
Справочник источников обращения. Содержит наименование источника обращения и его код в DNM-системе |
DNM Причины Отказа_Result |
Справочник причин отказа. Содержит наименование причины отказа и ее код в DNM-системе |
DNM Типы Событий_Event_type |
Справочник типов событий |
Рис. 4. Интерфейс формы обработки «Интеграция с DNM (обмен)»
В верхней части формы располагается название интеграционного модуля, а также логотипы разработчика и бренда, с которым будет работать данный модуль. Разработка не предусматривает выгрузки рабочих листов без участия человека, поэтому весь функционал реализован с помощью кнопок, добавленных на форму обработки. Общая иерархическая структура интеграционного модуля, включая добавленные и доработанные справочники, а также ключевые процедуры, представлена на рис. 5.
Рис. 5. Иерархическая структура интеграционного модуля Источник: составлено авторами
На форме обработки (вкладка Справочники) располагаются кнопки выгрузки справочников (рис. 6).
При нажатии кнопки «Синхронизировать» процедура «СинхронизацияСправочникаНаСервере()» передает в модуль формы метод, который определяет, какой именно справочник будет загружаться. Далее вызывается процедура GET_Запрос() модуля объекта. В нее отправляется метод, токен и адрес сервера из справочника «Настройки подключения». Подключение к DNM-системе происходит по протоколу HTTPs, все строки передаются в кодировке utf-8. Полезные данные передаются в формате JSON с указанием типа в заголовке.
Рис. 6. Страница синхронизации справочников Источник: составлено авторами
Для GET-запроса требуется только заполнение заголовка:
GET /api/model HTTP/1.1
Host: vaz.autocrm.ru
Connection: keep-alive
Accept: application/json
Authorization: Bearer YWRtaW5fbWFya2V0Q HVhei5ydTp0ZXN0
Первая строка запроса содержит протокол подключения и принимает метод в зависимости от загружаемого справочника. Параметры Host и Authorization заполняются токеном и адресом из настроек. Авторизация при подключении осуществляется посредством Bearer-токена, полученного от разработчика DNM-системы. Результатом GET-запроса является объект типа СтрокаJSON в которую записывается полученный ответ сервера:
[{ “id”: 404,
“name”: “LX”,
“brand_id”: 2082,
“model_id”: 21116,
“generation_id”: 14192,
“generation_name”: “1 поколение”,
“serie_id”: 57095,
“status”: 0,
“classification”: 7,
“is_new”: 0
}]
Чтобы полученный ответ можно было записать в справочники, СтрокуJSON необходимо преобразовать в объект с типом Соответствие и вызвать процедуру «СозданиеНовогоЭлементаСправочника()»:
НовыйЭлементСправочника = СсылкаНаСпра вочник(Метод).СоздатьЭлемент();
НовыйЭлементСправочника.Наименование = «ID: « + НовыйЭлементСправочника.DNM_ID + « / Name: « + НовыйЭлементСправочника.DNM_Name;
НовыйЭлементСправочника.Записать()
Если ответ от DNM пришел с ошибкой, то по уникальному коду ошибки пользователю высвечивается соответствующее сообщение и оформляется запись (лог) в текстовом документе, хранящем историю ошибок.
При работе с рабочими листами сотрудники будут использовать только справочники «Альфа-Авто», а выгрузка в DNM требует, чтобы выгружаемые данные соответствовали данным справочников DNM. Сопоставление загруженных справочников и справочников учетной системы дилера происходит по нажатию кнопки «Настройка». Она доступна лишь для части справочников, поскольку не все загружаемые справочники повторяют уже существующие в системе. При нажатии кнопки открывается форма списка справочника учетной системы дилера, пользователь вручную выбирает элементы для сопоставления. Ручной способ для настройки соответствия был выбран потому, что наименования элементов могут различаться в учетной системе дилера и DNM.
Рис. 7. Этапы отправки данных по рабочему листу
После выгрузки и сопоставления всех справочников можно переходить к выгрузке рабочих листов в DNM-систему. Данные по рабочим листам передаются из учетной системы дилера («1С: Альфа Авто») в двух случаях: если создан новый рабочий лист или же в ранее переданном рабочем листе произошли изменения.
Полнота передаваемых данных и перечень обязательных параметров при передаче рабочих листов определены техническим заданием от компании, причем список обязательных параметров меняется в зависимости от события (контракт, выдача, отказ и др.). На странице Документы формы обработки располагается поле списка. Добавление рабочих листов в него возможно с помощью кнопки «Добавить», а также кнопки «Подбор». При нажатии кнопки «Отправить РЛ в DNM» ссылки на выбранные документы отправляются в модуль объекта обработки. Отправка информации по рабочему листу происходит поэтапно, в соответствии с четырьмя методами полной выгрузки данных (рис. 7).
Методы последовательно передаются в процедуру «POST-Запрос», который, наряду с заголовком, содержит тело запроса. Заголовок заполняется идентично GET-запросу, но добавляется параметр Content-Type, в котором описан формат передаваемых данных. Передача осуществляется в формате JSON в кодировке utf-8:
POST /api/model HTTP/1.1
Host: vaz.autocrm.ru
Connection: keep-alive
Accept: application/json
Authorization: Bearer YWRtaW5fbWFya2V0QHVhei5ydTp0ZXN0
Content-Type: application/json; charset=UTF-8
Тело запроса заполняется в соответствии с методом, например заполнение тела запроса метода Client осуществляется следующим образом:
{
“name”: “Сергей”,
“middle_name”: “Сергеевич”,
“last_name”: “Семенов”,
“phones”: [{
“number”: “79061234567”,
“type”: 1
}],
“email”: “ssemenov@mail.ru”,
“address”: “Россия”,
“sex”: 1,
“code”: “client74388”,
“client_confirm_communication”: 1,
“may_process_personal_data”: 1,
«birthday»: «12.09.1978»
}
Данные документа «Рабочий Лист» записываются в объект типа Соответствие, который преобразуется в объект типа СтрокаJSON, при этом происходит замена значений реквизитов рабочего листа значениями из загруженных и сопоставленных справочников. Далее происходит отправка запроса на сервер и получение ответа:
{
«call»: «Звонок»,
«visit»: «Визит»,
«internet»: «Интернет обращение»,
«cold-call»: «Холодный звонок»,
«test-drive»: «Тест драйв»,
«offer»: «Коммерческое предложение»,
«contract»: «Контракт»,
«issue»: «Выдача»,
«comment»: «Комментарий»,
«reject»: «Отказ»
}
Ответ хранит в себе код состояния, а также полную информацию о созданной записи (все реквизиты). Полученный ответ читается с помощью функции «ДокументЧтениеJSON()», после чего реквизиты ID записываются в документ «Рабочий лист» в специально созданные отдельно для каждого отправленного метода реквизиты DNM_ID. Для метода Event запись происходит при помощи процедуры «ПолучитьИЗаписатьDNM_ID()» в реквизит «DNM_ID» в документе «Событие», так как по одному рабочему листу может быть несколько событий. Наличие заполненного реквизита DNM_ID сигнализирует о том, что отправка данных рабочего листа уже происходила ранее и создание новой записи не требуется. В этом случае используется процедура «PUT-запрос». PUT-запрос имеет незначительные отличия от POST-запроса:
PUT /api/client/31543 HTTP/1.1
Host: vaz.autocrm.ru
Connection: keep-alive
Accept: application/json
Authorization: Bearer YWRtaW5fbWFya2V0QHVhei5ydTp0ZXN0
Content-Type: application/json; charset=UTF-8
В заголовке в дополнение к методу указывается ID объекта (из реквизита DNM_ID), который нужно обновить. Тело запроса полностью идентично POST-запросу. Получаемый ответ читается, и происходит запись реквизитов DNM_ID. При получении от сервера ответа с ошибкой пользователю выдается сообщение об ошибке, происходит ее запись в лог. Возможна отправка сразу нескольких рабочих листов. В этом случае в соответствии с алгоритмом цикл запросов повторяется для каждого документа.
После доработки учетной системы и успешного подключения к DNM-системе был организован этап тестирования. Тестирование проводилось совместно с разработчиком DNM от лица сотрудника дилерского центра, при каждой успешной выгрузке ее результат сопоставлялся с ожидаемым. Для проверки корректности настройки интеграционного взаимодействия 1С: Альфа Авто с DNM-системой АВТОВАЗ были использованы представленные разработчиком тестовые сценарии, моделирующие различные варианты создания объектов в DNM-системе и поэтапное заполнение реквизитов Рабочих листов в зависимости от следующих параметров, характеризующих предпродажное взаимодействие дилера с клиентом:
– тип обратившегося в дилерский центр клиента (физическое или юридическое лицо);
– способ обращения клиента в дилерский центр (визит, звонок, обращение через сайт);
– возможный отказ от покупки после первого обращения к дилеру;
– варианты действий дилерского центра в зависимости от поведения клиентов после пройденного тест-драйва (подготовка коммерческого предложения, заключение контракта, дальнейшее взаимодействие с клиентом в целях продолжения консультационной поддержки, аллокация (бронь) VIN за клиентом);
– потенциально возможное приобретение клиентом нескольких транспортных средств.
Каждый из этих предполагаемых кейс-сценариев должен был обеспечить корректное добавление объектов в DNM-системе и заполнение атрибутов Рабочих листов, соответствующих специфике процесса взаимодействия с обратившимся в дилерский центр клиентом. По результатам анализа различных возможных вариантов предпродажного общения с клиентом были реализованы восемь различных тестовых кейс-сценариев:
1. Клиент обращается в дилерский центр с очным визитом, но после посещения отказывается от приобретения транспортного средства. В этом случае передача данных осуществляется в следующей последовательности: Создание в DNM-системе клиента-дилера → Создание Рабочего листа → Добавление потребности с указанием ID-потребности в ДМС Дилера → Создание в Рабочем листе DNM-системы события Визит с атрибутами из ДМС Дилера → Создание в Рабочем листе DNM-системы события Отказ с указанием даты события из ДМС Дилера и причины отказа от сделки.
2. Клиент обращается в дилерский центр и оставляет заявку на автомобиль посредством телефонного звонка, но после посещения отказывается от покупки транспортного средства. В этом случае в последовательность этапов первого сценария добавляется потребность в заполнении атрибутов рабочего листа, соответствующих событию.
3. Заявка на автомобиль поступает от клиента посредством заполнения формы на сайте. Сценарий предполагает визит клиента в дилерский центр, прохождение тест-драйва и формулирование для него коммерческого предложения. Каждый из этих шагов соответствует определенному событию (Интернет, Визит, Тест-драйв, Коммерческое предложение) в Рабочем листе DNM-системы, сопровождающемуся заполнением требуемых атрибутов. Сценарий завершается отказом от покупки автомобиля и формированием события Отказ в Рабочем листе.
4. После визита в дилерский центр и прохождения тест-драйва продавец-консультант продолжает предпродажное обслуживание и созванивается с клиентом по запланированному событию, но сценарий завершается отказом по Рабочему листу.
5. Сценарий дополняет предыдущий этап заключения контракта с клиентом, который соответствует обновлению атрибутов в карточке клиента дилера в DNM-системе и созданию события Контракт в Рабочем листе.
Рис. 8. Переход к основной инструкции пользователя на форме модуля
6. Посещение дилерского центра и тест-драйв происходят после оформления заявки на автомобиль по телефону. Клиент получает коммерческое предложение, с ним заключается контракт. Результатом сценария является выдача автомобиля с фиксацией данного факта посредством создания события Выдача в Рабочем листе DNM-системы.
7. Сценарий предполагает бронирование, заключение контракта и выдачу клиенту двух транспортных средств (VIN 1 и VIN 2) с заполнением расширенного перечня атрибутов по каждому событию Рабочего листа.
8. Данный сценарий предполагает предпродажное обслуживание клиента – юридического лица с последующей выдачей ему транспортного средства. В этой связи состав атрибутов клиента дилера расширяется и дополняется названием компании, формой собственности, контрактной информацией и указанием согласия на обработку персональных данных.
После получения подтверждения об успешной выгрузке тестовых рабочих листов по каждому из рассмотренных сценариев интеграционный модуль был перенесен в рабочую конфигурацию («1С: Альфа-Авто») дилера.
Следующим этапом разработки было обучение пользователей. С этой целью в рамках настоящего исследования разработана инструкция по использованию интеграционного модуля, доступ к которой добавлен на основную форму обработки через кнопку «Помощь». По нажатию открывается форма инструкции в виде поля HTML-документа, при открытии оно заполняется макетом с текстом инструкции (рис. 8).
Таким образом, в учетную систему «1С: Альфа-Авто» был добавлен интеграционный модуль, который позволил подключить ее к DNM-системе АВТОВАЗ и настроить синхронизацию их справочников и выгрузку рабочих листов из учетной системы дилера в DNM.
Заключение
Разработанный интеграционный модуль позволит полностью автоматизировать процесс оперативного получения автопроизводителем информации по каждой отдельной сделке дилерского центра, что предотвратит возможность ввода дилером заведомо ложных данных и представления искаженной информации по продажам и предпродажному взаимодействию с клиентами. В результате АО «АвтоВАЗ» будет оперативно получать полную детализацию данных и хронологию событий по каждой сделке дилерского центра в разрезе потребностей клиентов, причин отказов, менеджеров и т.д. Использованный подход к настройке интеграционного взаимодействия системы «1С: Альфа-Авто» с модулем продаж DNM-системы может быть распространен на последующую настройку обмена данными учетной системы с другими модулями DNM-системы, а также транслирован на другие типовые отраслевые конфигурации на базе платформы «1С: Предприятие» при настройке их интеграции с системами управления дилерскими сетями автопроизводителей.