Реєстр показує трьох отримувачів послуги. Насправді це одна людина: Олена Петренко, яку ввели тричі. Один раз правильно, один раз із зайвою крапкою після імені, і ще раз латиницею, бо в іншому відділенні так прийнято. Приклад умовний, але впізнаваний для будь-кого, хто працював із великим реєстром.
Звідки беруться дублікати
Дублікат рідко з'являється через недбалість. Частіше це наслідок того, як влаштований процес.
- Помилки під час введення. Зайвий пробіл, крапка, переставлені літери, «і» замість «ї». Для людини це той самий запис, для системи новий.
- Транслітерація. Одне прізвище можна записати латиницею кількома способами. Petrenko, Petrenco, Petrenka: кожен варіант формально інший.
- Новий документ. Людина змінила паспорт, прізвище після шлюбу чи отримала ID-картку. Старий запис ніхто не знайшов, тож створили новий.
- Різні точки введення. Онлайн-заява, центр надання послуг, імпорт із сусідньої системи. Кожен канал створює запис по-своєму, і ніхто не перевіряє, чи така людина вже є.
Що вони спотворюють
Найочевидніше: кількість. Якщо в реєстрі 10% дублікатів, звіт про охоплення завищений приблизно на стільки ж, і цю цифру потім порівнюють з планом. Причому завищення нерівномірне: там, де точок введення більше, дублікатів теж більше, тож і порівняння між регіонами чи відділеннями спотворюється.
Гірше, коли від запису залежать гроші. Два записи однієї людини можуть отримати дві виплати. Або навпаки: виплата прив'язана до старого запису, а людина вже звертається через новий і чує, що їй нічого не належить.
Це схоже на телефонну книгу, де одна людина записана як «Олена», «Олена робота» і «О. Петренко». Дзвонити незручно, але жити можна. (Аналогія неідеальна: телефон не перераховує вам гроші за кожен контакт.)
Як знайти ймовірні дублікати
Порівнювати записи лише за ПІБ замало: однакові прізвище та ім'я мають різні люди. Порівнювати лише за номером документа теж: документ змінюється. Тому для пошуку будують ключ із кількох полів:
- Прізвище й ім'я після нормалізації: без пробілів, крапок, з одним способом транслітерації.
- Дата народження.
- Номер документа без серії й розділювачів.
- РНОКПП або інший стабільний ідентифікатор, якщо він є.
Точний збіг ключа знаходить очевидні дублікати. Для решти використовують нечіткий збіг (fuzzy matching): алгоритм оцінює, наскільки схожі два записи, і пропонує пари з високою оцінкою.
Але пропонує, а не вирішує. Об'єднувати записи автоматично я б не радив: помилкове злиття двох різних людей виправляти значно важче, ніж знайти дублікат. Пари з високою оцінкою переглядає людина, яка знає процес. Алгоритм економить їй години, але не забирає рішення.
Головне рішення: який запис основний
Знайти дублікат легко. Складніше вирішити, що з ним робити. Для цього потрібні правила, а не кнопка «об'єднати»:
- Який запис лишається основним (master record) і за яким принципом: найстаріший, найповніший, підтверджений документом.
- Що відбувається з історією виплат і послуг, прив'язаною до інших записів.
- Хто погоджує об'єднання, якщо від нього залежать гроші.
- Як про зміну дізнаються інші системи, що зберігають посилання на старий запис.
Це питання управління даними, а не лише техніки. Без власника даних чистка дублікатів перетворюється на суперечку, чий запис правильніший.
Чому виправляти треба в джерелі
Найпоширеніша помилка: прибирати дублікати у звіті. Аналітик щомісяця пише чергове правило очищення, звіт стає правильним, а реєстр лишається таким самим. Наступного місяця все повторюється, і правило ще трохи ускладнюється.
Значно дешевше перевіряти під час введення. Коли оператор вводить нову людину, форма шукає схожі записи за тим самим ключем і показує їх: «Схожий запис уже є, це та сама людина?» Така перевірка працює один раз і назавжди, а не щомісяця.
Чого краще не робити
Кілька підходів, які виглядають розумно, але зазвичай роблять гірше:
- Видаляти дублікати. Видалений запис забирає з собою історію: звернення, рішення, виплати. Краще позначити запис як об'єднаний і зберегти посилання на основний.
- Довіряти одному полю. «Якщо РНОКПП збігається, це та сама людина» працює, доки в поле не потрапили нулі чи чужий номер. Ключ із кількох полів стійкіший.
- Чистити раз на рік великим проєктом. Після чистки дублікати знову накопичуються з тією самою швидкістю, якщо джерело не змінилося.
Кожен із цих кроків дає швидкий результат у звіті. І кожен відкладає справжню проблему: процес, який створює нові дублікати щодня.
Перевірте у себе
Візьміть свій основний реєстр і порахуйте дві цифри: кількість записів і кількість унікальних людей за ключем із кількох полів. Якщо друга помітно менша, ви знайшли не лише проблему якості даних, а й місце, де звіти про охоплення кажуть більше, ніж є насправді.
А ви знаєте, скільки людей у вашому реєстрі мають більше одного запису?