У CRM з’явилися два схожі записи клієнта. Автоматична перевірка пропонує об’єднання, проте договори й контакти відрізняються. В умовному прикладі відповідальний за довідник має вирішити, чи це дублікат, філія або інша юридична особа. Відповідь не можна замінити оцінкою схожості рядків.
Розділіть сигнал і підставу для зміни
Збіг назви, телефону або адреси допомагає знайти підозрілу пару. Він не доводить тотожність. Спільним номером можуть користуватися різні підрозділи, а одна організація може змінити адресу.
Опишіть, що система вважає сутністю: контрагента, підрозділ, контакт чи договірну сторону. Потім визначте джерела ідентифікації та умови, за яких рішення переходить до людини. Автоматичне правило має власника й межі застосування.
Призначте різні ролі різним рішенням
Власник даних погоджує бізнес-правило. Відповідальний за якість збирає докази й опрацьовує чергу винятків. ІТ налаштовує перевірки, журнал і технічне виконання. Одна людина може виконувати кілька ролей, але це має бути явним.
Британський Government Data Quality Framework розглядає якість через придатність до визначеної мети. Це корисна рамка для вибору перевірок, а не юридична вимога для українського бізнесу. У нашому прикладі мета має включати правильне збереження зв’язку з договорами, а не лише скорочення кількості рядків.
Перевірте залежності до об’єднання
Перелічіть договори, документи, відкриті звернення й аналітичні набори, які посилаються на обидва записи. Для кожного поля визначте, яке значення залишається і чому. «Останнє змінене» не завжди означає «правильне».
Якщо доказів бракує, залиште пару в черзі з відповідальним і наступною дією. Не видаляйте запис, щоб прибрати попередження. Потрібно також знати, як відновити зв’язки, якщо об’єднання виявиться помилковим.
| Ситуація | Дія | Що перевірити |
|---|---|---|
| Схожі назви, різні ідентифікатори | Не об’єднувати лише за назвою | Тип сутності та підтверджені джерела |
| Одна сутність, різні контакти | Погодити значення полів | Актуальність і призначення контакту |
| Недостатньо доказів | Залишити виняток відкритим | Власник і наступна перевірка |
Залиште рішення, яке можна пояснити
Журнал має містити початкові ідентифікатори, підставу, погодження, перелік змінених зв’язків та час операції. Перевірка після об’єднання повинна дійти до систем, що використовують довідник. Успішна команда в MDM ще не означає, що звіт або договір отримав правильний запис.
E-Data Consulting допомагає визначити ці правила перед налаштуванням довідників і процесів у рішеннях Intecracy Group. Конкретні можливості журналювання та відновлення перевіряються на вибраному продукті. Для першого пілоту оберіть кілька різних типів спірних пар, а не лише очевидні дублікати.
Питання та відповіді
Чи може ІТ бути власником даних?
Може, якщо йдеться про дані його власного процесу. Технічний доступ сам по собі не надає повноважень визначати бізнес-значення клієнта.
Чи можна автоматично зливати очевидні дублікати?
Лише в межах погодженого правила, перевіреного на представницькій вибірці, із журналом і визначеним відновленням. Неоднозначні пари потребують окремого розгляду.
Джерело та метод
Government Data Quality Framework. Приклад і порядок приймання вище є редакційним методом, а не цитатою зі стандарту чи описом реального клієнтського кейсу.