Не пускать плохие данные

🌐 Также доступно на 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 выставляет счет розничному партнеру, юридические реквизиты партнера должны быть верными. Если представитель набрасывает заметки после встречи, никому не нужен комитет, утверждающий каждое предложение. «Достаточно хорошо» — это бизнес-определение; архитектор делает его измеримым и обеспечиваемым.

Предотвращайте дорогие ошибки

Не каждое плохое поле заслуживает одинакового внимания. Больше всего меня волнуют ошибки с последствиями ниже по потоку. Дубликат клиента означает две истории продаж, две истории обслуживания, два набора контактов, два внешних ID, две интеграции, синхронизирующие одну и ту же компанию, две версии в хранилище и в Data 360, а в итоге — агента, который решает, какой клиент настоящий. Это гораздо дороже опечатки в описании. Поэтому не начинайте с вопроса «как нам проверять каждое поле?». Начните с вопроса какие плохие данные создают самую большую проблему для бизнеса или архитектуры? — и ставьте самые сильные средства контроля там.

Открыто или закрыто?

Классический пример — создание организаций (Account). Должен ли каждый продавец иметь возможность создать организацию? Мой ответ: это зависит от управления вокруг данных. Для большинства малых и средних 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 приходят внутрь.

Трудный случай это не убирает. Представитель конвертирует интерес (Lead) для 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, загрузка данных или интеграция все равно могут записать поле. Настоящее обеспечение — это безопасность на уровне полей или правило проверки; проверка в интерфейсе — не проверка данных (глава 3, модуль 9). Типы записи по-прежнему оправдывают себя, когда двум видам организаций нужны разные значения списков выбора или бизнес-процессы. А важно вот что: какое-то поле должно ясно говорить, откуда пришла запись: сам ключ ERP, флаг мастер-данных или список выбора источника. И тогда управляйте возможностью редактирования от этого поля.

Click to enlarge

От предварительной к управляемой: продажи начинают продавать сразу; только авторитетный процесс делает запись управляемой.

Защитите управляемую запись

Когда клиент возвращается из ERP, его ID в ERP, юридическое название, налоговый идентификатор и платежные реквизиты становятся управляемыми атрибутами. Должен ли представитель их менять? Нет, если ими владеет ERP. Это политика из модуля 1, которой нужна точка обеспечения: ID из ERP только для чтения, юридические реквизиты под контролем, а представитель по-прежнему редактирует территорию, заметки об отношениях и собственные классификации Salesforce. Цель — не неприкасаемая организация. Цель — ясная граница между данными, которыми владеет Salesforce, и данными, на которые Salesforce только ссылается. (Префикс erp_ из главы 4 делает эту границу видимой в схеме.)

В итоге получается золотая запись, которая на самом деле гибридная. Мастер-поля 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. Поле заполнено; данные — мусор. Прежде чем что-то требовать, спросите, знает ли пользователь это на данном этапе. Если нет, требуйте это позже в процессе, пусть значение предоставит другая система, используйте предварительное состояние или предложите явное Unknown (неизвестно), когда «неизвестно» — законный ответ. Правило проверки может обеспечить политику. Но оно не может заставить человека знать то, чего он не знает.

Каждой границе данных нужно решение о качестве

Люди — не единственный источник плохих данных; интеграции производят их быстрее. Приходит манифест розничного партнера на несколько сотен строк. В нескольких из них недействительные почтовые индексы, в паре указан неизвестный распределительный центр, две повторяют один и тот же номер заказа. Что происходит? Отклонить весь файл? Принять хорошие строки и вернуть плохие? Загрузить все и почистить потом? Отправить исключения в карантин? Кому сообщают и как партнер узнает, что не прошло? Универсального ответа нет, но ответ должен быть. Глава 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).