Глеб Галкин

У большинства компаний более одного интерфейса взаимодействия с клиентами. И практически наверняка есть несколько массивов данных, представляющих клиентов. Если эти данные конфликтуют, а они не могут не конфликтовать, управлять отношениями с клиентами становится гораздо труднее. Обслуживание клиентов, маркетинг и продажи -- во всех этих областях можно получить дополнительную выгоду, устранив несогласованность данных.

На больших предприятиях данные о клиентах обычно хранятся во многих прикладных системах -- фронт-офисных (системы автоматизации отдела продаж, управления заказами и центр обработки вызовов), бэк-офисных (ERP-системы и системы учета и управления поставками собственной разработки). Понятно, что в этой ситуации клиентские данные дублируются.

Причем дублируются, так сказать, логически, а не формально точно. В каждом приложении собственная модель данных, как правило, представляет одного и того же клиента различными способами, с различными идентификаторами и параметрами. Например, для учета кодировок в различных странах почтовый индекс в одном приложении может представляться в формате "5 + 4", а в другом -- девятью символами.

В каждом приложении есть свои особенности семантики и методы проверки корректности данных. Например, правила семантики гарантируют, что прежде, чем записи справочной информации клиента обновлены, дата рождения клиента не будет позже текущей даты. Или адрес клиента будет находятся в заданном формате. И понятно ,что в разных приложениях эти правила разные.

Более того, проблемы с данными имеются и внутри одного приложения. Когда приложения модернизируются, эти правила могут несколько изменяться. В результате данные клиента в одном приложении начинают менять формат и, в некоторых случаях, даже структуру. Если этот процесс идет в течение долгого времени, информация практически всегда становится непоследовательной и неточной. В результате разработчикам приходится вручную писать массу кода, призванного обеспечить интеграцию и непротиворечивость дублирующихся клиентских данных с самыми разными наборами атрибутов.

Некоторые компании пробовали решить эту несогласованность, рассматривая определенное приложение как единственный правдивый источник для определенных типов данных клиента. Однако это очень трудно выполнить в ситуации, когда компания пользуется разнообразными каналами взаимодействия с клиентами. Например, если при покупке (или контакте с компанией) по одному каналу клиент указал номер своего мобильного телефона, а при контакте по другому каналу -- домашнего, то в обоих приложениях будет правильная информация. Но если вы рассматриваете как единственно правильное только одно из этих приложений, то правдивая информация из второго будет потеряна.

Другие компании пробовали решить эту проблему, стандартизируя данные в одном бизнес-приложении, которое покрывает все предприятие. Но этот подход не очень практичен: Большинство бизнес-приложений не могут поддерживать все каналы общения с клиентами в пределах большой компании. Сегодня есть два основных подхода к решению проблемы несогласованности данных клиентов.

Подход 1: централизованное хранилище семантики

Первый подход основан на создании централизованного хранилища семантической информации. Он исходит из следующего предположения: если правила хранения клиентских данных отделить от самих данных, то данные клиентов будут всегда оставаться корректными при изменении приложений и добавлении новых. Поэтому надо централизовать все правила на различных этапах обработки данных (проверка данных, преобразование, агрегация и т. д) в одном общем хранилище и делать их доступными различным приложениям. Все правила, связанные с изменением данных при взаимодействии приложений, смоделированы и управляются в одном хранилище, вместо того чтобы быть закодированными в нескольких приложениях или дополнительном интеграционном слое. Единое хранение этих правил облегчает их обновление. А оно определенно будет необходимо, чтобы ответить на изменения в бизнесе компании.

Как правило, сейчас доступ к набору правил приложения получают через Web-сервисы. Сервис, например "обновление профиля клиента", просто вызывается м, получает данные, применяет к ним набор правил семантики и затем отдает обратно приложению. Когда одно из приложений модернизируется, то, возможно, должны будут измениться и правила преобразования данных, но отнюдь не придется переписывать интерфейс между приложениями. Такое решение уменьшает с тоимость поддержания прикладной интеграции.

Подход 2: мастер-склад

Второй подход подразумевает, что проблема непоследовательных и неточных данных клиентов может быть решена лучше, если всю важную информацию о клиенте объединить в едином месте. И этот так называемый "мастер-склад" используется как единственный источник правды для всех приложений.

Здесь надо сказать, что имеет смысл делить данные, находящиеся в любом бизнес-приложении, на три типа: фактологические, транзакционные и произведенные. Эти типы данных имеют различные характеристики, и большинство приложений оперируют со всеми этими тремя типами. Фактологические данные обычно включают признаки, описывающие клиента, имя, адрес и телефонный номер, которые вводятся в систему извне и очень редко могут изменяться. Транзакционные данные представляют исторические данные о клиенте, типа последних десяти закупок. Такие данные фиксируются приложением в результате работы. Наконец, произведенные данные -- это факты, которые произведены от других данных с использованием математических операций. Здесь данные могут быть агрегированы, например, в рамках групп клиентов, чтобы добиться обобщения.

Таким образом, фактологические данные -- это лишь небольшая часть данных о клиенте, но именно они доставляют массу хлопот при управлении и поддержании информационной целостности. Вполне понятно, так как именно они легче всего дублируются в разных приложениях и быстро становятся непоследовательными и неточными. Но излишне говорить, что без фактологических данных нельзя точно соединить транзакционные и вычислить произведенные данные.

Поэтому подход централизованного хранилища семантической информации начинается с того, чтобы устранить несогласованность и улучшить точность именно фактологических данных, консолидируя их из различных приложений в едином месте. Эта консолидация совсем не так проста, потому что получается следующая картина. Данные о 5 тыс. клиентах с 25 атрибутами из одного приложения надо объединить с 8 тыс. клиентов с 40 атрибутами из другого и с 300 клиентами, имеющими 60 атрибутов, из третьего приложения.

При этом атрибуты достаточно разные, а на выходе должно получиться полная база о всех клиентах (без дублирования) с каким-то количеством атрибутов (явно не менее 60, но скорее всего - больше). Но главная проблема в том, что у этих данных еще и разная степень достоверности (в одном приложении - 80%, а в другом может быть только 50%). Достоверность результирующей информации должна быть повышена до 95-99%.

Как только эти фактологические данные объединены в мастер-складе, он становится источником правды для всех фактологических данных в пределах предприятия. Все приложения обязаны синхронизировать свои собственные данные с этим источником. При этом если клиент связывается с компанией и информирует об изменении номера кредитной карточки или мобильного телефона, то такое изменение прежде всего должно попасть в "мастер-склад", а не в приложение, обслуживающее этот канал связи с клиентом. И здесь есть определенная проблема, так как обеспечить такой порядок действий можно в плоскости организационных регламентов, но не ИТ-систем. Ну а когда в мастер-складе данные клиента изменяются, то он принудительно обновляет эту информацию в других приложениях.

Каким путем пойти?

Два подхода, описанных выше, используют разные тактики, чтобы решить проблему интеграции данных о клиентах. Подход централизованного хранилища семантической информации оставляет данные распределенными по соответствующим приложениям и централизует только правила. Подход мастер-склада, напротив, централизует ключевые данные клиентов в общем хранилище. При этом оба подхода оказываются вполне состоятельны в реальных проектах.

Идеального рекомендуемого во всех случаях подхода сейчас нет. Опят показывает, что конкретный путь компании может зависеть от многих факторов: объема данных о клиентах, частоты изменения данных, природы приложений компании и т. д. Но все же тем или иным способом проблема непоследовательных данных о клиентах должна быть решена.