How to: привести в порядок данные логистической компании
В HFLabs обратились заказчики из крупной логистической компании. Их цель — подготовить IT-инфраструктуру к новым бизнес-задачам, сделать ее масштабируемой и прозрачной. Этому мешали проблемы, причины которых крылись в организации данных.
Из-за специфики хранения данных колл-центр порой не узнавал звонящих. А, например, маркетинг не понимал, какой канал коммуникации эффективен для каждого клиента.
Мы завершили проект, впервые применив адресный MDM: сделали центром модели данных в компании адреса́, а не клиентов. Эта концепция идеально подошла логистическому бизнесу.
Рассказываем, почему MDM вокруг клиентов — не всегда лучший вариант для логистики и грузоперевозок, как поставить адреса́ в центр модели данных и какую пользу проект принес заказчику.
MDM вокруг клиента = проблемы с масштабированием
Логистическая компания оперирует адресами и маршрутами между ними, в ее бизнес-процессах именно адрес — главный элемент. Клиент же, физ- или юрлицо, выступает как атрибут а́дреса.
Но в архитектуре, которую много лет назад применил заказчик, все ровно наоборот: адреса́ являются атрибутами клиентов. Когда модель данных расходится с бизнес-логикой, получаешь ворох проблем с масштабированием: в маркетинге, аналитике, сервисе.
Исторически IT-архитектура компании служила главной цели: доставить заказ. Куда следует, кому следует, за правильную цену и в срок. Базу подстраивали под эту задачу так, чтобы не делать резких изменений и не рисковать. Выбранной архитектуры при таком подходе хватило бы еще на много лет.
Заказчик пришел к HFLabs не потому, что IT-инфраструктура трещит по швам и разваливается. Все работало и без нас. Цель проекта — подготовиться к новым бизнес-задачам: улучшению клиентского сервиса, маркетинга, аналитики.
Константин Степанов, директор по работе с ключевыми клиентами HFLabs
Действующая модель, накладываясь на особенности оформления доставки, плодила в базе компании дубли. Например, для новых заказов клиенты появлялись в базе в четырех разных ролях:
- контрагент — платит за доставку;
- отправитель;
- получатель;
- контактное лицо.
Дмитрий (1) отправляет Василию (2) велосипед в офис, в Балашиху. Посылки для Василия принимает секретарь (3). При этом на въезде на территорию центра стоит будка охраны (4). Охрану нужно предупредить о доставке.
В итоге адрес Василия связан сразу с четырьмя людьми. Но в базе данных связь между ними не отражена, там просто появляются четыре записи с одинаковым адресом в атрибутах. А телефон охраны вовсе не привязан к реальному человеку.
Если же заказать перевозку самому себе, вообще появишься в базе компании четыре раза в четырех разных качествах.
С юрлицами еще сложнее: у них больше контактных лиц, а еще нужно хранить людей с правом подписи и реквизиты компании.
Адреса́ в базе тоже дублируются, потому что каждый новый заказ порождает адресную запись. Больше заказов — больше адресов.
Со временем в компании заметили, что дубли мешают развитию:
- грузы доставляют не туда. Операторы заполняют адрес доставки на слух и порой ошибаются. Фуры приезжают не туда, это обходится очень дорого. Причем в базе лежит правильный адрес, оставшийся с одного из прошлых заказов. Но найти нужный вариант среди вороха дублей невозможно;
- маркетинговые кампании летят мимо цели. Непонятно, кому и по каким номерам из базы звонить с предложениями, по каким адресам делать маркетинговые рассылки. А иногда клиент получает несколько одинаковых звонков или писем;
- невозможно рассчитать статистику — начиная с того, сколько вообще клиентов у компании. В базе огромное количество записей в разных ролях, поди разберись.
Задача HFLabs вместе с заказчиком — решить проблемы, разработав новый прозрачный формат хранения данных.
Адресный MDM подходит идеально
Мы предложили заказчику адресный MDM, обсудили детали и дело пошло́. Цель — организовать данные так, чтобы поставить в центр адрес. Эта модель очевидным образом подходит для логистики.
При классическом подходе все данные собирают вокруг клиентов. А клиентов различают по ФИО, году рождения, телефону, номеру паспорта. Наша задача — построить систему вокруг адресов. Причем так, чтобы каждый было легко идентифицировать.
Чтобы отделить адреса один от другого, мы их для начала стандартизируем. То есть разбираем на составляющие по уровням — всего их тридцать. А затем сравниваем по всем уровням сразу. Совпадают — адреса одинаковые, нет — разные. Иногда алгоритм не уверен, такие случаи проверяют дата-стюарды.
В исходной базе лежит два адреса: г Москва, ул Королева, д 12 к 2 и Москва, Королева, 12/2. Разобрать автоматически, один и тот же это адрес или разные, невозможно. По формальным правилам нумерации 12/2 и д 12 к 2 — разные дома. Но люди часто записывают корпус через дробь, и наш алгоритм это знает.
Поэтому пара адресов уйдет на ручную проверку.
И уже на адреса́, отделенные друг от друга, мы «нанизываем» карточки клиентов: получателя, отправителя, контактного лица.
В старой модели физические и юридические лица, относящиеся к адресу доставки, никак друг с другом не связаны. В новой, зная адрес, как на ладони видишь все связанные физ- и юрлица
Новую базу для заказчика мы построили на своем «Едином клиенте». Название продукта прозрачно сообщает, что «из коробки» он группирует данные вокруг клиентов, не адресов. Поэтому пришлось основательно перепилить движок.
Сделали адреса доставки главным элементом базы. Теперь адрес — это не атрибут клиента, а полновесная сущность. У каждого есть своя карточка и набор свойств.
У каждого адреса — собственный идентификатор и карточка
Нашли и схлопнули дубли адресов. Объединяя дубли, «Единый клиент» собирает все известные данные об адресе в одну карточку:
- геокоординаты;
- тип здания;
- площадь квартиры;
- стоимость квартиры и квадратного метра;
- ссылки на все записи, где встречается адрес;
- заметки об адресе из всех записей, хранящихся в базе.
Допустим, к одной записи об адресе оператор добавил ориентир — «Поворачивать у школы налево». Ко второй записи — телефон вахтера.
В общую карточку адреса попадет и заметка об ориентире, и номер телефона.
К адресу привязывают физических и юридических лиц в разных ролях
Привязали клиентов к адресам. В новой модели адрес не привязан к конкретному клиенту в качестве контакта. Наоборот, это у а́дреса есть контактные лица.
В заказе указали контактное лицо, которому нужно звонить с вопросами. Еще одному человеку нужно прислать смс о доставке. Естественно, у груза есть еще и отправитель.
Чтобы все это отразить в базе, к адресу привязывают:
- человека, который является контактным лицом;
- человека, которому нужно скинуть смс;
- отправителя.
Собрали данные о клиентах, «размазанные» по базе. Раньше клиенты хранились в базе как разные записи с разными ролями: адресат, получатель, контактное лицо и т. д.
Теперь у клиента одна карточка, в ней — ФИО, контактные данные, реквизиты документов и все остальное, что известно компании.
Данные о прошлых клиентах больше не нужно собирать по разным записям. Все, что известно — в единой карточке
Почистили дубли клиентов. Дублированных клиентов порой сложно найти простыми алгоритмами. Так случается из-за опечаток или разного набора реквизитов в записях об одном клиенте.
| Запись А | Запись Б | |
|---|---|---|
| ФИО | Травин Коля | Николай Сергеевич Травин |
| Телефон | (495) 960-42-42 | 960-42-42 |
| Дата рождения | 31.03.1984 | |
| Паспорт | 7701 359743 |
«Единый клиент» проанализировал базу, нашел скрытые дубли и объединил в общие карточки. Теперь база компании чище, а данные о клиентах — полнее.
Привели в порядок адреса́, хранящиеся в базе. «Единый клиент» привел все адреса́ к общему формату — теперь их печатают на документах без дополнительной проверки. Также он разделил адреса́ на гарантированно верные, гарантированно неверные и те, которым требуется ручной разбор.
Результат — база компании готова к новым бизнес-задачам
Мы загрузили в «Единый клиент» данные обо всех клиентах — физических и юридических лицах, во всех ролях. Карточки клиентов объединили вокруг адресов, данные не приходится собирать из размазанных по базе дублей.
Теперь база данных отвечает задаче заказчика — повысить уровень клиентского сервиса. Компания планирует улучшить:
- маркетинг, чтобы связываться с каждым клиентом по удобному каналу;
- доставку, чтобы привозить грузы по верным адресам и без проблем связываться с контактными лицами;
- сервис, чтобы узнавать клиентов при звонке в колл-центр и выставлять счета без ошибок в реквизитах.
Завершенный проект — целиком инфраструктурный, мы заложили фундамент. Теперь к единой базе понемногу прикручивают бизнес-процессы.
Например, с новым MDM бухгалтерия заказчика всегда без ошибок выставляет счета. Раньше в них порой попадали устаревшие реквизиты.
Чтобы исключить ошибки, «Единый клиент» ежедневно сравнивает сохраненные реквизиты контрагентов со свежим ЕГРЮЛ. Расхождения собирает в специальный отчет, который можно автоматически выгружать в любом формате.
В нашем случае заказчик формирует из отчета excel-файл, который попадает к ответственному сотруднику. Тот связывается с контрагентами и обновляет реквизиты в базе.
«Единый клиент» не меняет данные автоматически, потому что контрагенты не давали на это формального согласия.
Константин Степанов, директор по работе с ключевыми клиентами HFLabs
Если бизнес имеет дело с адресами, наладим IT-инфраструктуру
В 2019 году адресный MDM у заказчиков HFLabs неслыханно популярен. Он подходит не только логистическим и транспортным компаниям, прямо сейчас мы работаем над проектом для телекома.
Федеральный интернет-провайдер запустил обзвон клиентов и предлагает домашний интернет. Многие соглашаются, потому что раньше не знали о такой возможности.
Проблема в том, что помимо системы учета клиентов у компании есть еще одна система — с технической информацией. Именно там описана зона покрытия услуг, там выясняют возможность подключения интернета по адресу.
У отдела маркетинга есть контакты клиентов, но нет доступа к техническим данным. Не факт, что каждому человеку из списка для обзвона можно подключить услугу. В итоге провайдер вынужден отказывать людям, которым сам же и предложил домашний интернет.
Маркетинг оператора будет куда дешевле и эффективнее, если интегрировать систему учета клиентов и техническую систему. Это пример задачи, которую мы решаем для заказчика.
Разберемся в задачах, составим отчет о проблемах с данными и расскажем, как их решить. Для крупного бизнеса от 100 000 клиентов — бесплатно, за три дня.
Оставить заявку на пилотный проект — ask@hflabs.ru.
