Як не пустити погані дані

🌐 Також доступно 28 мовами

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Зображення згенеровано ШІ

Перекладено ШІ. Спільнота ще не перевірила. Читати англійською

Модуль 2 з 6 розділу Якість даних і врядування, розділ 5 курсу Data Architect. Кожен модуль самостійний. Попередній: Врядування закладається в org · Наступний: Знайте свої дані

Питання, на яке відповідає цей модуль: Як зробити дані добрими і такими їх зберегти?

Є два способи впоратися з поганими даними: зупинити їх до того, як вони потраплять усередину, або прибрати потім. Ви робитимете і те, й інше. Але якщо є вибір, я радше запобіжу проблемі, ніж збудую організацію навколо вічного прибирання. Дублікати, хибні ідентифікатори, відсутня інформація, нестандартні значення, користувачі, що змінюють поля, якими володіє інша система, інтеграції, що перезаписують добрі дані поганими: усе це стає чиїмсь проєктом із прибирання. Тож проєктне запитання — які погані дані я можу розумно не пустити від самого початку? А «розумно» важливе, бо відповідь — не закрити кожне поле, доки система не стане непридатною.

«Достатньо добре» — бізнес-визначення

Перш ніж запобігати поганим даним, визначте добрі. Одного визначення немає. Добре може означати: достатньо повне, щоб процес працював, достатньо точне, щоб на ньому ухвалювати рішення, достатньо актуальне для навантаження, достатньо узгоджене, щоб поєднувати з іншими системами, достатньо унікальне, щоб знати, якого клієнта ми маємо на увазі, достатньо стандартне для автоматизації, достатньо простежуване, щоб знати, звідки воно. Це залежить від даних. Якщо Steve Trucking виставляє рахунок роздрібному партнерові, юридична ідентичність партнера має бути правильною. Якщо продавець занотовує щось після зустрічі, нікому не потрібен комітет, що погоджує кожне речення. «Достатньо добре» — бізнес-визначення; архітектор робить його вимірюваним і таким, що його можна забезпечити.

Запобігайте дорогим помилкам

Не кожне погане поле заслуговує однакової уваги. Найбільше мене хвилюють помилки з наслідками нижче за потоком. Дубльований клієнт означає дві історії продажів, дві історії сервісу, два набори контактів, два External ID, дві інтеграції, що синхронізують ту саму компанію, дві версії у сховищі даних і в Data 360, а зрештою — агента, що вирішує, котрий клієнт справжній. Це набагато дорожче за друкарську помилку в описі. Тож не починайте з «як нам перевіряти кожне поле?» Почніть із які погані дані створюють найбільшу бізнес- чи архітектурну проблему? і поставте найсильніші контролі там.

Відкрите чи закрите?

Створення акаунтів — класичний приклад. Чи має кожен продавець мати змогу створити акаунт? Моя відповідь: це залежить від врядування навколо даних. Для більшості малих і середніх org відкрите створення годиться. Продавець зустрічає потенційного клієнта, створює акаунт, береться до роботи; для цього й існує CRM. Якість підтримують правила дублікатів, обов’язкова інформація і стюардство. Я не додаю важкого процесу погодження лише тому, що врядування звучить відповідально.

А тепер змініть ландшафт. Юридичний клієнт керується в ERP, тече в Salesforce з ідентифікатором ERP, і ERP авторитетна. Тепер відкрите створення означає два способи створити ту саму керовану сутність. Коли і ERP, і продавець створюють ту саму компанію, хто перемагає, яким ідентифікатором користуються інтеграції, який запис тримає історію? Відкрите створення перестає бути питанням зручності й стає питанням основних даних. Коли акаунти керуються в ERP чи синхронізуються з нею, закрийте створення.

Але закрити повністю — теж провал. Продавець зустрів потенційного клієнта, якого немає в ERP, і хоче відкрити можливість, а модель врядування каже «акаунта не буде». Тож він три дні чекає фінанси, або чіпляє можливість не до того акаунта, або тримає потенційного клієнта в полі нотаток чи таблиці. Ми захистили модель даних і зашкодили бізнесу.

Середній шлях: тимчасовий тип запису

Ось середній шлях, який мені подобається. Дозвольте продажам створювати акаунт під окремим типом запису — потенційного чи тимчасового — і контролюйте його перетворення на керований тип. Продажі фіксують компанію й починають продавати. Запис прямо каже: ще не встановлено в авторитетній системі. Потім контрольований процес його перетворює: фінанси погоджують, або інтеграція подає його в ERP, яка або зіставляє з наявним клієнтом, або створює нового й надсилає назад авторитетний ідентифікатор. Тепер запис перетинає межу, тимчасовий → керований, а це зовсім не те саме, що дві системи, кожна з яких створює те, що вважає головним записом.

Тип запису — механізм, якого я навчаю. Хоч би що ви використовували, зробіть стан видимим у даних: звідки прийшов запис, чи перетнув він межу, хто може змінювати його тепер і ідентифікатор, що пов’язує його з авторитетною системою. ID клієнта в ERP, що існує лише після перетворення, — найясніший сигнал з усіх.

Тип запису для кожного потоку

Покладіть увесь потік на один малюнок, і ви побачите, чому це працює. Клієнти й продукти приходять усередину з ERP. Можливості та їхні позиції йдуть назовні і стають замовленнями ERP. А акаунти? Деякі приходять усередину, деякі йдуть назовні. Тож поширений шаблон, який я бачив у різних впровадженнях, — два типи запису на Account, по одному для кожного напрямку. Акаунт Sales народжується в Salesforce: менеджери з продажу створюють його, редагують, продають йому, а коли він стає клієнтом, його надсилають назовні в ERP. Акаунт ERP (я називав його Customer або просто SAP) народжується в ERP і приходить через інтеграцію. Цей тип запису не створює ніхто, крім інтеграції, а його поля основних даних (юридична назва, адреси, умови оплати) для користувачів лише для читання. Тип запису каже вам, у який бік тече запис, тож напрямок керування видно просто на записі.

Click to enlarge

Тип запису для кожного потоку: акаунти Sales ідуть назовні, акаунти ERP приходять усередину.

Складного випадку це не прибирає. Менеджер конвертує лід для Steve’s Plumbing, але Steve’s Plumbing уже існує як акаунт ERP, і перевірка дублікатів якось цього не впіймала. Тепер ви зливаєте записи, переприв’язуєте дочірні й вирішуєте, який запис виживе (розділ 6, модуль 3).

І не зациклюйтеся на самому типі запису. Зазвичай я уникаю типів запису, якщо немає вагомих підстав. Тут я використав їх тому, що до Dynamic Forms (динамічних форм) тип запису обирав макет сторінки, і один макет показував поля ERP лише для читання. З Dynamic Forms правила видимості можуть показувати й ховати поля за значенням поля, поле може бути лише для читання на певній сторінці, і сам Salesforce каже, що Dynamic Forms зменшують кількість потрібних макетів сторінок і типів запису (Break Up Your Record Details with Dynamic Forms (opens in a new tab); Required and Read-Only Fields in Dynamic Forms (opens in a new tab)). Але лише для читання на сторінці — це лише для читання на цій сторінці: API, завантаження даних чи інтеграція все одно можуть записати поле. Справжнє забезпечення — це безпека на рівні полів або правило перевірки; перевірка в UI — не перевірка даних (розділ 3, модуль 9). Типи запису досі заслуговують на своє місце, коли двом видам акаунтів потрібні різні значення списків вибору чи бізнес-процеси. Важливо ось що: якесь поле має чітко казати, звідки прийшов запис: сам ключ ERP, позначка основних даних чи список вибору джерела. А тоді керуйте можливістю редагування від цього поля.

Click to enlarge

Від тимчасового до керованого: продажі починають продавати одразу; лише авторитетний процес робить запис керованим.

Захистіть керований запис

Щойно клієнт повертається з ERP, його ID в ERP, юридична назва, податковий ідентифікатор і реквізити для рахунків — керовані атрибути. Чи має продавець їх змінювати? Ні, якщо ними володіє ERP. Це політика з модуля 1, що потребує точки забезпечення: ID в ERP лише для читання, юридична ідентичність під контролем, а продавець досі редагує територію, нотатки про стосунки й власні класифікації Salesforce. Мета — не недоторканний акаунт. Мета — чітка межа між даними, якими володіє Salesforce, і даними, на які Salesforce посилається. (Префікс erp_ з розділу 4 робить цю межу видимою в схемі.)

Зрештою ви отримуєте golden record, який насправді є гібридом. Поля основних даних ERP приходять усередину: юридична назва, адреси для рахунків і доставки, умови оплати. Потім Salesforce додає власні поля, які ніколи не повертаються назад: рейтинг продажів, дату останнього замовлення, майже все, чим користується маркетинг. Той самий акаунт, два види полів, і кожен вид має одне джерело.

Найскладніше — це двобічні потоки. Скажімо, менеджерові треба змінити юридичну назву в ERP зі Steve’s Plumbing на Steve’s Plumbing LLC. У ті самі п’ять хвилин хтось в ERP змінює її на Steve’s Plumbing L.L.C. Чия зміна перемагає? Ось правильне мислення: якщо полем керує ERP, ви не змінюєте поле, ви просите його змінити. Вирішіть, що стається, коли запит стикається з іншою зміною: перемагає ERP, запит відхиляється, якщо значення тим часом змінилося, або він чекає, доки людина розв’яже колізію. І вирішіть, чи пов’язані поля їдуть разом як одна зміна, чи по одному. Розділ 6 розвиває тему колізій (Цикли й колізії).

Зупиняйте дублікати біля дверей

Дублікати накопичуються. Зловіть один до створення — і це маленька проблема. Знайдіть його через два роки, коли на обох висять можливості, звернення, контакти, рахунки, інтеграції й аналітика, — і це велика проблема. Модуль 7 розділу 3 розглянув механізми (правила зіставлення, правила дублікатів, унікальні External ID), тож я не викладатиму їх знову. Запитання врядування — де ми мусимо запобігати дублюванню, а де стерпимо його й розв’яжемо пізніше? Випадковий маркетинговий лід може жити з неоднозначністю. Клієнт під врядуванням ERP із фінансовими транзакціями — ні.

Стандартизуйте те, що читають машини

Вільний текст чудовий для людей і жахливий, коли його має інтерпретувати система. Покладіть Arizona, AZ, Ariz., Phoenix area і Southwest у поле, що керує маршрутизацією, — і у вас проблема якості. Якщо значення керує автоматизацією, інтеграцією, звітністю, безпекою, призначенням чи дією агента, добре подумайте, наскільки стандартним воно має бути. Не кожне текстове поле стає списком вибору, але відрізняйте інформацію, яку читають люди, від інформації, на основі якої вирішують машини. Друга заслуговує сильнішого контролю.

Не дайте обов’язковим полям створювати фальшиві дані

Ми вирішуємо, що поле важливе, і робимо його обов’язковим. Користувач не знає відповіді, система не пускає далі, тож він вводить N/A, Unknown, 999999 чи test@test.com. Поле заповнене; дані — сміття. Перш ніж щось вимагати, запитайте, чи користувач справді знає це на цьому етапі. Якщо ні, вимагайте пізніше в процесі, дайте іншій системі це надати, використайте тимчасовий стан або запропонуйте явне Невідомо, коли «невідомо» — легітимна відповідь. Правило перевірки може забезпечити політику. Воно не може змусити когось знати те, чого він не знає.

Кожній межі даних потрібне рішення про якість

Люди — не єдине джерело поганих даних; інтеграції створюють їх швидше. Маніфест роздрібного партнера приходить із кількома сотнями рядків. У кількох неправильні поштові індекси, у парі вказано невідомий розподільчий центр, два повторюють той самий номер замовлення. Що станеться? Відхилити весь файл? Прийняти добрі рядки й повернути погані? Завантажити все й почистити пізніше? Поставити винятки на карантин? Кому повідомлять і як партнер дізнається, що не пройшло? Універсальної відповіді немає, але вона має бути. Розділ 4 сказав, що кожній стрілці потрібен механізм. Додайте: кожній межі даних потрібне рішення про якість: що ми приймаємо, відхиляємо чи ставимо на карантин і хто володіє винятком.

Click to enlarge

Кожній межі даних потрібне рішення про якість.

Історичні дані — інша справа

RouteDesk містить вісім років історії Steve Trucking, і її якість різниться залежно від розподільчого центру. Чи варто чистити всі вісім років до сьогоднішнього стандарту, перш ніж переносити? Мабуть, не автоматично. Для чого вони: щоденні операції, довідка, претензії, звітність, аналіз трендів? Чи все має бути в Salesforce, чи частина може лишитися деінде? Розділ про міграцію іде вглиб. Суть для врядування: історія не потребує автоматично того самого стандарту, що й активні дані. Якщо ви ухвалюватимете на них рішення, якість важлива. Якщо зберігаєте для довідки, може вистачити іншого стандарту. Знайте мету, перш ніж витратити статки на чищення минулого.

Вимірюйте те, на що хтось відреагує

Врядування ніколи не завершене, тож вам треба бачити, коли якість просідає: зростає частка дублікатів, більше записів на карантині, більше відхилень інтеграцій, поширюються значення-заглушки, більше запитів на обхід, звіти більше не сходяться. Але не будуйте 150 метрик, щоб ігнорувати 143. Для Steve Trucking це, можливо, доставки без дійсного посилання на партнера, доставки без придатної адреси, повторювані номери замовлень, відхилені повідомлення партнерів, акаунти, що застрягли в тимчасовому стані. Дашборд, повний зелених кружечків, не означає, що дані добрі. Вимірюйте те, на що хтось готовий відреагувати.

За межами іспиту: що змінює ШІ. Погані дані дедалі частіше стають поганою дією. Людина може помітити, що номер телефону виглядає неправильно, перш ніж зателефонувати; агент просто використовує дане значення. Дубльовані клієнти, застарілі статуси, фальшиві обов’язкові значення і хибні ідентифікатори прямо перетворюються на не те повідомлення чи не те оновлення. Це підвищує цінність запобігання. Це не прибирає потреби в стюардстві.

Що тут вирішує архітектор

• Які збої якості завдають достатньо шкоди, щоб виправдати запобіжні контролі.
• Чи керовані записи створюють вільно, лише в авторитетній системі чи через шлях «тимчасовий → керований».
• Якими атрибутами Salesforce володіє, а на які лише посилається.
• Що стається з вхідними даними, що не пройшли перевірки (прийняти, відхилити чи поставити на карантин), і хто володіє винятком.
• Які сигнали якості вимірюються, щоб стюарди бачили просідання.

Ви ніколи не запобіжите кожному поганому запису. Робота — не ідеальні дані; вона в тому, щоб не дати поганим даним, яких можна уникнути, стати дорогими даними. Зупиніть дублікат, перш ніж у нього з’явиться дворічна історія. Захистіть ідентифікатор, перш ніж десять інтеграцій залежатимуть від неправильного. Дайте продажам створити потенційного клієнта, але не вдавайте, що це керований клієнт, доки ним не стане. А коли щось погане таки проскочить, переконайтеся, що хтось може це побачити, взяти на себе й виправити.

Додаткові матеріали

• Salesforce Help, Things to Know About Duplicate Rules (opens in a new tab) (англійською, перевірено 2026-10-14).
• Salesforce Help, Break Up Your Record Details with Dynamic Forms (opens in a new tab) і Required and Read-Only Fields in Dynamic Forms (opens in a new tab) (англійською, перевірено 2026-10-14).