Конференция "Прочее" » Профайлы клиентов в автоматизированной системе
 
  • DayGaykin © (14.12.18 13:24) [0]
    Есть некий бизнес у которого есть клиенты, много клиентов.

    И вот архитектор создает логичную структуру базы данных:
    - Клиенты;
    - Заявки, которые ссылаются на клиента.

    В таблице клиентов все "чинно-благородно". ФИО, дата рождения, паспорт, контакты.

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

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

    Вопрос, как быть? Какие в этом направлении лучшие практики?
  • ухты © (14.12.18 14:17) [1]
    А вы автоматом себе в базу заливаете? А зачем?
  • ухты © (14.12.18 14:19) [2]
    Еще вопрос про архитектора... это вы штоле? или почему не он этим занимаетеся?
  • Inovet © (14.12.18 15:08) [3]
    Для отсева некоторой части повторов можно проверять какие-то данные о клиенте, которые обычно обязательные, и имеют внутреннюю проверку валидности, ИНН - его сложно ввести криво при наличии проверки. СНИЛС, если физ лицо, тоже с проверкой. Вот паспорт не додумались так сделать, слова по этому поводу произносить не буду, но в 21 веке же, блин, вводили новый паспорт.
  • KSergey © (15.12.18 11:49) [4]
    Во-первых, ясно дать понять, что архитектор существует для бизнеса, а не бизнес для архитектора. (А то почитал тут статейку на хабре, где чувак гордился, как он у "тупых менеджеров" выбивает себе и друзьям з/п, причем упорно апеллируя к тому, что менеджеры - тупые; смешно, короче.)

    Что касается описанной ситуации (именно в той последовательности, как описано), то с учетом

    > Когда клиент приходит, его профайл, конечно корректируют,

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

    Это не значит, что база в какой-то момент станет кристально чистой, нет, это просто обычная рутина должна быть в компании дабы поддерживать бизнес-процессы в приемлемом качестве.

    > но и тут могут ошибиться.

    Вот это не понял, признаться.
    Если ошиблись - ну счастья-то не будет. хоть на этапе первичного заведения данных, хоть на этапе их корректировки. Не понятно что тут вообще возможно сделать.
    Ну разве что приделать распознавание паспорта, где-то такие видел/читал, дабы уменьшить кол-во ошибок при первичном вводе данных.
  • FreeAndNil © (15.12.18 14:27) [5]
    ночные субботники. явка всех роботов предприятия строго обязательна.
    все готовят данные для дневного принятия решения людьми.
    https://dadata.ru/api/
  • manaka © (15.12.18 19:44) [6]

    > И вот архитектор создает логичную структуру базы данных:


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


    > Какие в этом направлении лучшие практики?


    Все сжечь и переделать.
  • Тимохов Дима © (15.12.18 19:52) [7]
    Мое имхо:
    1. Наведение порядка в данном случае - ручной труд.
    2. Дать возможность оператору, наводящему порядок, хорошие инструменты:
      а. Поиск возможных кандидатов на объединение.
      б. Удобным механизм слияния.
  • KSergey © (15.12.18 22:19) [8]
    > manaka ©   (15.12.18 19:44) [6]
    > А бить по рукам пользователей, которые забивают паспорт
    > 111111 начальнику лень.

    Сказано же: сторонний сервис. Кому по рукам бить?

    > manaka ©   (15.12.18 19:44) [6]
    > Все сжечь и переделать.

    Молодой ты еще, горячий. Всё бы "переделать" всех кругом.
  • Тимохов Дима © (16.12.18 00:17) [9]
    Добавлю. Вообще, такие вещи решаются имхо в директивном порядке:
    а. Выбирается сотрудник, ответственный за порядок.
    б. Ему вменяется в обязанность наведение порядка.
    в. Ему даются средства наведения порядка.
    г. Придумывается критерий успешности его работы.

    Человека еще рано списывать в утиль. Как-то так.
  • картман © (16.12.18 01:32) [10]

    > Какие в этом направлении лучшие практики?

    Вот, книжку рекомендуют: https://www.ozon.ru/context/detail/id/19613873/
  • niteshade © (19.12.18 11:56) [11]
    >manaka ©   (15.12.18 19:44) [6]

    >А уникальный идентификатор клиента архитектор не придумал.
    допустим, придумал
    и архитектор сторонней системы придумал
    и эти два идентификатора даже совпадут
    с вероятностью, стремящейся к нулю

    >А проверять записи при интеграции сторонних баз программист не догадался.
    в исходной системе: 50 01 111111 Иванов Иван Иванович
    в сторонней: 50 01 111111 Петров Пётр Петрович
    в какой из систем ошибка?
    проверяйте, нам не жалко

    >А бить по рукам пользователей, которые забивают паспорт 111111 начальнику лень.
    1. системы сторонние;
    2. от ошибок ввода никто не застрахован.

    >Все сжечь и переделать.
    такие переделкины с гордо поднятой головой идут на рынок труда, подгоняемые ветром
    из головы
  • KSergey © (19.12.18 19:47) [12]
    > niteshade ©   (19.12.18 11:56) [11]
    > такие переделкины с гордо поднятой головой идут на рынок
    > труда, подгоняемые ветром
    > из головы

    Они вполне успешны
    Так что не стоит завидовать )
  • niteshade © (21.12.18 08:02) [13]
    >KSergey ©   (19.12.18 19:47) [12]
    >Они вполне успешны
    >Так что не стоит завидовать )
    мнение не изменю
    завидовать не перестану)
  • ухты © (22.12.18 00:12) [14]
    чем же дело кончилось ...
  • DayGaykin © (26.12.18 15:41) [15]
    Пока идея такая.
    Будут профайлы проверенные и непроверенные.

    Когда от внешней системы приходит заявка, для нее создается непроверенный профайл.

    Когда администратор будет обрабатывать заявку он увидит, что профайл не проверен и сделает одно на выбор действие:
    1. Пометит профайл как проверенный и корректно заполнит его.
    2. Выберет на свое усмотрение уже существующий проверенный профайл, а непроверенный полностью удалится.

    Для того, чтобы администратор мог выбрать правильное действие, ему в интерфейсе будет показан список всех проверенных профайлов, которые так или иначе по разным наборам признаков совпадают в исходным непроверенным.
  • ухты © (26.12.18 21:27) [16]
    уболтали архитектора? ))
  • KSergey © (27.12.18 07:04) [17]
    Его просто убрали.
 
Конференция "Прочее" » Профайлы клиентов в автоматизированной системе
Есть новые Нет новых   [118232   +39][b:0][p:0.001]