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