Цели и задачи проекта по внедрению MDM
Ожидаемые бизнес-эффекты:
- Снизить вероятность ошибок в операционных бизнес-процессах, связанных с использованием устаревших данных о клиентах.
- Снизить трудозатраты операционистов, исключив необходимость повторного ручного ввода уже существующих в Банке данных.
- Обеспечить постоянное улучшение качества клиентских данных и обозримость процессов преобразования данных.
- Использовать достоверную и полную информацию о клиентах для формирования отчетности.
- Упростить создание и запуск новых бизнес-приложений.
Стратегически, внедрение MDM позволяет перестать тратить из-за некачественных данных и необходимости поддерживать множество интеграций, и начать извлекать прибыль из данных. Если один раз навести порядок в основных данных и построить надежные процессы поддержания их качества, в будущем можно будет сэкономить на операционных затратах как ИТ-блока, так и бизнес-подразделений. Еще более важно то, что внедрение MDM создаст фундамент для развития ИТ-инфраструктуры, то есть более быстрого и эффективного внедрения новых технологий и прикладных инструментов для автоматизации бизнес-процессов и аналитики. Срок и стоимость внедрения таких инноваций существенно сократится, а их результат будет более качественным. В том числе, любые инструменты искусственного интеллекта имеет смысл внедрять только тогда, когда наведен порядок в данных, которые они используют. Данные должны быть снабжены связью с контекстом и аннотированы явно заданным смыслом.
Задачи проекта и последовательность его реализации:
- Выполнить первоначальную загрузку из ИТ-систем Банка данных о клиентах – физических лицах и индивидуальных предпринимателях, а также о связанных с ними документах, адресах и др. Реализовать централизованное обновление данных из систем-источников и государственных баз данных.
- Настроить автоматические процессы обработки данных: нормализацию при загрузке из систем-источников, валидацию и контроль качества, объединение сведений об одном бизнес-объекте из разных систем.
- Сформировать эталонные данные с выбором наиболее актуальных значений каждого свойства.
- Настроить пользовательский интерфейс для мониторинга качества всех данных, просмотра их происхождения, истории преобразований, выполнения операций над выборками данных.
- Распространить эталонные данные во все бизнес-приложения, где они используются. Предоставить API для полнофункционального доступа к данным и их структуре, включая возможность получения обновлений данных по подписке.
Загрузка данных о клиентах из систем-источников
Задача MDM – эффективно использовать существующую в Банке информацию, преобразовать ее автоматизированным способом для обеспечения ее доступности и доверия. Это означает, что внедрение MDM не должно создавать новых процессов ручного ввода данных, а должно быть максимально сконцентрировано на извлечении, валидации и использовании той информации, которая уже собирается в рамках существующих процессов.
В любом Банке используется несколько автоматизированных систем, каждая из которых предназначена для автоматизации определенных бизнес-процессов: ведения счетов, карточного процессинга, выдачи кредитов, дистанционного обслуживания. В каждой из этих систем хранятся и обрабатываются клиентские данные. В зависимости от того, какими услугами пользуется клиент и каким способом он взаимодействует с Банком, сведения о клиенте могут содержаться и обновляться в разных системах. При обновлении сведений о клиенте, таких как данные его документов или место проживания, информация часто обновляется только в одной системе, которая соответствует каналу, по которому обратился пользователь.
Состав данных в разных системах также отличается. Например, для принятия решения о выдаче кредита нужно больше сведений о клиенте, поэтому кредитные системы содержат более широкий набор свойств. Последовательность шагов по загрузке данных в платформу MDM из систем-источников такова:
1. Создать эталонную модель данных, которая будет включать все свойства и типы информационных объектов, доступные из разных систем. Эту работу выполняют системные аналитики, опирающиеся на данные анализа бизнес-процессов и ИТ-систем. При составлении эталонной модели данных нужно понимать, в каких процессах появляются значения тех или иных свойств, как они используются, какие требования предъявляются к их значениям.
2. Построить мэппинг (правила соответствия) между элементами эталонной модели и структурой данных в конкретных источниках. Это тоже работа аналитиков, начальная фаза которой может быть частично автоматизирована, если в компании уже используется каталог данных, построенный с помощью таких инструментов, как OpenMetaData.
3. Выполнить первоначальную загрузку данных из каждой системы. Адаптер, входящий в состав платформы DataVera EKG Platform, подключается к источникам, загружает и преобразует информацию в соответствии с правилами мэппинга.
4. Настроить режим постоянного обновления данных из каждого источника. Информация об обновлении данных из систем-источников может быть доступна разными способами: через витрину DWH (Data Warehouse), посредством веб-сервисов, с помощью механизма подписки. Один из наиболее удобных способов отслеживания изменений данных в базах систем-источников – использование механизма CDC (Change Data Capture).
В ходе развития Банка, при появлении новых бизнес-процессов и изменении существующих, в том числе из-за появления новых требований регулятора, структура эталонных данных и правила мэппинга будут меняться. Очень важно, чтобы они не были запрограммированы в системе. Аналитик должен иметь возможность управлять структурой и правилами мэппинга по ходу работы системы. DataVera EKG Platform обеспечивает такую возможность благодаря использованию спецификаций онтологического моделирования W3C для хранения машинно-читаемого описания структуры данных и правил. Редактировать их можно с помощью визуального пользовательского интерфейса.
В платформе управления данными каждый бизнес-объект, такой как клиент, представлен как набор информационных объектов из источников данных, из которых затем создается эталонный объект. Сначала необходимо загрузить «зеркальные» копии каждого объекта из каждой системы-источника, применив к ним правила преобразования и очистки. Затем эти копии группируются по ключевым признакам, чтобы объединить карточки одного бизнес-объекта, и из каждой группы формируется одна эталонная запись. В структуре данных платформы объекты из источника и эталонные объекты относятся к разным подклассам (типам): так, класс «Персона» имеет подклассы «Персона из источника данных» и «Эталонная персона». Набор свойств объектов этих подклассов может отличаться: например, «Персона из источника данных» хранит версии значений каждого свойства до и после нормализации, а «Эталонная персона» содержит ссылки на все объекты из источников, участвовавшие в ее формировании.
Для загрузки данных из источников в платформу необходимо создание адаптеров. Это программные компоненты, которые обращаются к каждому источнику тем способом, который для него возможен, получают последние изменения данных и сохраняют их как объекты из источника данных. В состав нашей платформы входит универсальный адаптер для подключения к любым реляционным БД и получения последних изменений в данных с помощью механизма CDC. Тот же адаптер применяется и для первоначальной загрузки данных при внедрении системы. Адаптер выполняет преобразование структуры данных из модели системы-источника в модель, настроенную в платформе. Также он преобразует значения свойств, которые ссылаются на элементы справочников-перечислений – например, приводит к одному стандарту пол клиента или тип документа, преобразует формат дат, контролирует длину строк.
Источниками данных могут выступать не только собственные ИТ-системы Банка, но и внешние сервисы, такие как государственные базы данных. В Казахстане это ГБД ФЛ, государственная база данных физических лиц, которая содержит основные данные о гражданине, его документах и адресах. Обращение к гос. базе возможно после получения согласия от клиента и выпуска специального токена. В нашей платформе реализовано автоматическое обращение в ГБД ФЛ при каждом обновлении информации о клиенте.
На этапе создания модели данных и загрузки информации из источников важно обратить внимание на следующее:
1. Нужно создавать модель эталонных данных, опираясь на требования бизнеса к составу данных, а не на технологические особенности реализации тех или иных систем Банка и заложенную в них структуру.
2. Предусмотреть возможность изменения структуры данных по ходу работы системы после ее запуска в эксплуатацию. Для этого должны быть реализованы инструменты управления структурой данных и правилами их загрузки из источников.
3. Провести анализ структуры и способов формирования данных в каждой системе-источнике. Важно определить наборы допустимых значений каждого поля в каждой системе, применяемые там правила форматно-логического контроля, режим обновления данных. Все эти факторы влияют на то, как данные будут поступать в платформу и обрабатываться в ней. Например, если в какой-то из фронтальных систем реализовано автосохранение карточки клиента в процессе ее редактирования – до того, как операционист полностью закончит ввод данных – на стороне платформы нужно предусмотреть возможность поступления неполных или не подтвержденных данных от этой системы, многократную перезапись одного и того же объекта.
4. Особенно важно исследовать способы формирования идентификаторов объектов в каждом источнике. В некоторых случаях в системе-источнике не формируются уникальные идентификаторы объектов, либо идентификаторы могут использоваться повторно после удаления объектов. В таких случаях для однозначной идентификации каждого информационного объекта из источника необходимо использовать набор значений ключевых свойств.
5. В некоторых системах структура хранения может быть не нормализована – например, один бизнес-объект может описываться несколькими строками одной или разных таблиц БД, могут применяться таблицы-связки и др. Синтаксис правил DataVera EKG Platform и алгоритмы адаптера загрузки данных позволяют обработать такие случаи.
6. Необходимо настроить инструменты мониторинга входящего потока данных, которые будут предупреждать операторов системы об ошибках и сбоях, таких как временная недоступность того или иного источника, появление неожиданных значений свойств. Особенно это важно для свойств, имеющих мэппинг на справочники-перечисления; например, если платформа ожидает от какой-то системы в поле «Пол» значения M и F, а приходит значение X, это является инцидентом, на который нужно обратить внимание оператору. Он должен либо дополнить справочник и таблицу мэппинга, либо устранить неверное значение в источнике.
Настройка автоматических процессов обработки данных
Рассмотрим подробнее, как происходит обработка клиентских данных после того, как копия информационного объекта из системы-источника попадает в платформу. Адаптер преобразует сведения о бизнес-объекте, полученные из какого-либо приложения Банка, в ту универсальную структуру, в которой данные должны храниться в платформе. После этого адаптер отправляет в платформу запрос на запись объекта.
Данные в системах-источниках могут быть «грязными». Типичные проблемы включают дублирование пробелов и дефисов, несогласованность регистра в разных приложениях, подмену одинаково выглядящих букв разных алфавитов – например, использование английских букв «а», «о», «е» и др. в именах, написанных на кириллице. Чтобы исключить подобные проблемы, в момент записи данных в платформу происходит нормализация. Применяются правила, настроенные аналитиком в визуальном интерфейсе платформы. Правила могут удалять лишние спецсимволы, приводить строки к определенному регистру, форматировать номера телефонов и т.д. В свойствах объекта из источника данных в платформе сохраняются и исходное значение, полученное из источника, и результат нормализации. Это позволяет отслеживать правильность очистки.
Правила нормализации исключают проблемы, которые могут быть исправлены автоматически. Но большая часть проблем требует вмешательства пользователя для того, чтобы принять верное решение по корректировке данных. Для этого нужно пометить ошибочные или подозрительные значения свойств объектов, чтобы дата-стюарды могли их откорректировать или обратиться к бизнес-подразделениям за уточнением информации. Чтобы решить эту задачу, применяются правила форматно-логического контроля, которые могут:
- Проверять значения отдельных полей на соответствие шаблону. Например, ИИН должен состоять из 12 цифр, а номер телефона должен начинаться с кода оператора и состоять из 10 цифр.
- Выполнять взаимные проверки нескольких полей. Так, первые 6 цифр ИИН соответствуют дате рождения клиента, а 7-я цифра отражает пол для резидентов. Страна гражданства должна быть заполнена для клиентов-нерезидентов.
- Выполнять перекрестные проверки нескольких объектов разных типов. Так, гражданство клиента должно соответствовать типу документа, удостоверяющего личность.
В реальных проектах создаются сотни таких правил. Важно, что платформа предоставляет единую точку для обзора и управления всеми правилами. В каждом приложении Банка могут быть реализованы некоторые из этих правил, и при изменении бизнес-логики необходимо вносить изменения в каждое из приложений; при этом не всегда известно в точности, какие правила реализованы в каждой системе. Централизованное управление правилами через платформу снимает эту неопределенность. Более того: если Банк самостоятельно разрабатывает те или иные приложения, например единую фронт-систему для операциониста – эта система может получать определения правил из платформы и применять их на своей стороне, либо обращаться к платформе для валидации конкретных объектов. Это снимает риск того, что при изменении бизнес-логики изменения забудут внести на стороне какого-то из приложений, либо они будут внесены в разных системах в разное время, что приведет к появлению не согласованных между собой данных.
Что делать при обнаружении ошибки форматно-логического контроля? Бизнес должен принять решение о том, какие типы нарушений являются критичными, а какие – могут оставаться в эталонных данных до момента устранения. Значения свойств, имеющих критичные нарушения, не должны попадать в эталонный объект. Так, недопустимо появление эталонных объектов с ИИН = 000000000000, телефоном +7700000000 и так далее. При обнаружении таких нарушений платформа записывает в специальный журнал критичную ошибку ФЛК. Эта ошибка должна быть передана сотрудникам бизнес-подразделения, которые взаимодействуют с клиентом, чтобы они могли уточнить данные. После внесения уточненных данных обработка объекта продолжается, и создается эталон.
Примерами не критичных нарушений можно считать ситуации, когда номер телефона не начинается с кода оператора (это может быть иностранный номер), срок действия документа меньше текущей даты и др.
Похожий принцип применяется и к контролю обязательности наличия значений свойств. Некоторые свойства критически важны, и без них эталонный объект не может быть создан: это ИИН, номер телефона, дата рождения и др. Другие свойства в принципе нужны, но эталонный объект можно создать и без них: кодовое слово, место рождения, сегмент клиента и др.
Важно, что в любом случае нарушения ФЛК относятся только к определенным полям карточки клиента. Нарушения не блокируют создание эталонной записи в целом, если только не допущено критическое нарушение в значении обязательного поля – например, не верен ИИН.
Как мы указывали выше, каждый реальный объект – например, клиент – может иметь несколько карточек в разных источниках. Их необходимо объединить в группы для того, чтобы сформировать один эталонный объект для каждого бизнес-объекта. Для этого нужно определить набор ключевых полей, которые однозначно идентифицируют объекты каждого типа. Для идентификации клиента достаточно ИИН (если это обязательное поле), документа – номера и даты выдачи.
В DataVera EKG Platform правила группировки объектов реализованы с помощью механизма правил логического вывода, которые могут дополнять значения свойств объектов. Пример формулировки такого правила: если объекты класса «Персона из источника данных» имеют одинаковый ИИН, то необходимо связать их специальной связью.
При создании правил обработки данных в платформе нужно обратить внимание на следующее:
1. Внимательно выбирать уровень толерантности в правилах ФЛК. На практике приходится балансировать между желанием иметь идеальные данные и ограничениями реальных бизнес-процессов, в которых не всегда можно сразу получить полный набор данных о клиенте. Например, в процессе онбординга задача бизнеса – заинтересовать клиента банковским продуктом, таким как кредит, не требуя от него ввода большего объема информации, чем требуется для принятия предварительного решения о возможности выдачи кредита. Слишком строгие правила могут помешать обслуживанию клиентов, а слишком мягкие – ухудшат возможности создания аналитики.
2. Исторические данные, которые загружаются в платформу при ее запуске, заведомо содержат большое количество ошибок ФЛК. Возможно, при загрузке старых данных правила придется ослабить для того, чтобы получить эталонную запись по каждому клиенту. Затем, уже в процессе работы с платформой, организовать процесс верификации и дополнения накопленной информации.
3. Нарушений ФЛК в любом случае будет немало. Нужны механизмы, которые позволят организовать процессы а) немедленного реагирования на появление новых критичных ошибок, б) постоянного совершенствования данных путем устранения накопленных не критичных ошибок. Для управления этими процессами нужны инструменты мониторинга, которые визуализируют метрики качества данных, связанные с количеством нарушений ФЛК, и позволяют отслеживать динамику их изменения.
4. Важно разделить работу по устранению нарушений ФЛК между сотрудниками службы управления данными и бизнес-подразделениями, взаимодействующими с клиентами. Служба управления данными не может самостоятельно принимать решения о корректировке данных, если только речь не идет об устранении технических ошибок или о загрузке информации из доверенного источника, такого как государственные сервисы. Для изменения большей части клиентских данных необходима верификация их источника, которую могут обеспечить только подразделения, взаимодействующие с клиентом. Инструменты и процессы, описанные в пунктах 3 и 4, позволяют достичь одной из важнейших целей проекта по внедрению MDM – обеспечить постоянное улучшение качества клиентских данных.
5. При нормализации клиентских данных банков нельзя полагаться на ИИ. Решения о автоматической коррекции данных могут приниматься только на основе детерминированных алгоритмов, утвержденных ответственными сотрудниками от бизнеса и системными аналитиками.
6. Набор правил и их логика могут меняться из-за изменения бизнес-требований. Должен быть предусмотрен процесс внесения изменений в правила, который могут выполнять аналитики без вмешательства в программный код. Необходима возможность применять новую редакцию правил к накопленным данным.
Формирование эталонных объектов
После того, как завершены все этапы обработки информации из источников, нужно сформировать эталонные данные. Так как каждый эталонный объект может формироваться из нескольких исходных объектов из разных систем, возникает вопрос о том, как выбирать значения свойств. Например, в одной системе-источнике указан телефон клиента +77012345678, а в другой +77059876543. Как решить, какой телефон должен оказаться в эталонной карточке?
Решение зависит от того, как устроены бизнес-процессы Банка, и как они взаимосвязаны с автоматизированными системами. На практике чаще всего встречаются два варианта:
- Самое свежее, последнее по времени значение свойства можно считать актуальным. Такой подход применяется в случаях, когда сведения о клиенте могут измениться со стороны любого бизнес-приложения в зависимости от того, каким образом и с какой целью он обратился.
- Установлен приоритет, определяющий порядок предпочтительных источников для каждого свойства. Этот способ подходит, если одним системам (например, АБС) можно доверять больше, чем другим.
Чтобы определить, какое значение свойства является самым свежим, DataVera EKG Platform хранит полную историю изменения значений всех свойств каждого объекта. Это позволяет собирать эталонный объект из значений свойств, хранящихся в разных системах. Например, если клиент сообщил о смене резидентства при визите в офис, эти сведения будут отражены в АБС, а если он сменил номер телефона для уведомлений – эта информация поступит со стороны приложения ДБО. В любом случае, в эталонном объекте окажется последняя версия статуса резидентства и последний, актуальный номер телефона.
Может оказаться, что по какой-то причине эталонный объект нельзя сформировать. Это может произойти при отсутствии значений для свойств, обязательных при консолидации: например, телефон обязателен для эталонного объекта, но его нет ни в одной карточке из систем-источников. Другой вариант – наличие в одной системе-источнике дубликатов объектов с одинаковыми значениями ключевых свойств, например существование двух карт клиента с одинаковым ИИН в какой-либо системе. Такие правила настраиваются аналитиком при внедрении платформы. В ходе эксплуатации системы важно отслеживать появление подобных ошибок и оперативно их устранять, дополняя или исправляя клиентские данные. Платформа предоставляет для этого несколько возможностей: журнал ошибок, подписку на уведомления или сводки ошибок, экспорт метрик количества ошибок для отображения в дэшбордах средств мониторинга.
На что нужно обратить внимание при работе с эталонными объектами:
1. Не стоит редактировать эталонные объекты напрямую, если обнаружена какая-то проблема с данными. В этой статье мы описываем консолидирующий паттерн проектирования MDM, при котором первоисточником любых изменений являются бизнес-приложения. Значит, и исправлять обнаруженные ошибки нужно на уровне этих приложений. Эталонные объекты должны быть доступны только для чтения, а изменять их могут только штатные процессы консолидации.
2. Идентификаторы эталонных объектов должны быть уникальными и не несущими смысловой нагрузки. Лучше всего использовать guid.
3. В большинстве случаев нельзя удалять эталонные объекты, так как на них могут остаться ссылки из других систем. Если карта какого-либо клиента удаляется из бизнес-приложений, на уровне MDM лучше пометить соответствующий эталонный объект специальным флагом, но не удалять его. Исключение – удаление персональных данных по требованиям законодательства.
Пользовательский интерфейс MDM и обозримость процессов работы с данными
Подразделение по управлению данными, а в некоторых случаях – и пользователи со стороны бизнеса, заинтересованы в визуальных инструментах быстрого поиска данных, создания аналитических выборок, мониторинга процессов передачи и преобразования информации.
Мы уже упоминали некоторые функциональные возможности, обеспечивающие мониторинг и отслеживание изменений в данных. Перечислим все инструменты, обеспечивающие сотрудникам подразделения по управлению данными полную картину текущего состояния данных и процессов их обновления:
- Мониторинг ошибок загрузки данных помогает контролировать непрерывность и правильность хода загрузки данных из систем-источников, реагировать на изменения структуры и появление неожиданных значений в исходных данных.
- Запись истории всех изменений объектов из источников данных и хранение исходных версий значений свойств позволяет проверять ход преобразования и очистки данных при загрузке, а также формирует информацию о дате и времени изменения свойств объектов.
- Журнал ошибок ФЛК позволяет контролировать вновь возникающие и накопленные ошибки в данных, для устранения которых требуется вмешательство персонала. Дэшборды позволяют отслеживать динамику качества данных.
- Журнал ошибок консолидации позволяет оперативно реагировать на ситуации, когда о каком-либо бизнес-объекте недостаточно данных, в системе-источнике возникли дубликаты, либо существуют критические ошибки ФЛК. Отработка этих ошибок дата-стюардами вместе с сотрудниками бизнес-подразделений должна привести к ситуации, когда вся информация в системах-источниках откорректирована в соответствии с требованиями бизнес-процессов.
- Запись сведений о происхождении значений свойств эталонных объектов позволяет контролировать, какие процессы обновления данных в бизнес-приложениях привели к формированию или обновлению эталонных объектов данных. Для каждого эталонного объекта можно получить полную картину его происхождения и историю изменений.
- Журнал исходящих ошибок передачи данных предназначен для контроля за процессами тиражирования эталонных данных в приложения-потребители. Это могут быть те же приложения, что выступают источниками данных, или инструменты аналитики, такие как BI.
- Журнал аудита действий пользователей системы позволяют сотрудникам службы безопасности удостовериться в том, что все клиентские данные используются строго в рамках полномочий работников.
Для работы со всеми этими функциональными блоками EKG Platform предоставляет пользовательский интерфейс. Он позволяет просматривать как сами данные, так и технологическую информацию об их обработке, и аналитические представления. Через интерфейс доступна работа со структурой данных и всеми видами правил. Интерфейс поддерживает создание аналитических выборок, импорт/экспорт информации в Excel, навигацию между связанными объектами данных.
Важные аспекты интерфейсов и обозримости данных:
1. Ни один шаг обработки не должен оставаться внутри «черного ящика». Для того, чтобы бизнес-пользователи могли доверять данным и аналитике, построенной на их основе, необходимо добиться полного понимания пути преобразования данных как на уровне принципиальной схемы, выраженной в правилах, так и на уровне прослеживания происхождения конкретных объектов.
2. У сотрудников подразделения по работе с данными есть задачи по построению выборок как по объектам, загруженным из источников, так и по эталонным данным. Те и другие должны быть доступны в интерфейсе и разделены, чтобы пользователь однозначно понимал, с каким набором данных работает.
3. Для каждого вида возможных ошибок и нарушений, регистрируемых платформой, должны быть определены ответственные сотрудники и подразделения, которые должны реагировать на их появление и устранять проблемы. Ошибки не должны просто накапливаться в журналах.
Распространение эталонных данных и доступ через API
После того, как эталонные данные созданы и процесс их обновления налажен, собранную нужно необходимо использовать. Для этого необходимо доставить эталонные данные в приложения, в которых работают сотрудники Банка, выполняющие бизнес-процессы. Такими приложениями могут быть:
- те же системы, что являются источниками данных для консолидации,
- аналитические витрины, или
- новые дата-центрические приложения.
Диаграмма сценария обмена для первых двух видов потребителей выглядит так:
Такой сценарий обеспечивает достижение одной из основных целей проекта по внедрению MDM: добиться актуальности данных во всех системах независимо от того, со стороны какой из них произошло обновление сведений о клиенте. Например, если контактные данные клиента обновлены в мобильном приложении ДБО, они должны попасть в остальные системы банка, такие как CRM и кредитную систему. Платформа позволяет настраивать пути распространения данных в зависимости от того, какая именно информация и в ходе какого процесса была изменена. Благодаря такому способу распространения эталонных данных также достигается снижение числа ошибок в бизнес-процессах, связанных с использованием не актуальных данных клиента.
Этот сценарий помогает снизить и трудозатраты операционистов в некоторых сценариях обслуживания клиентов. Например, при онбординге нового клиента обычно необходимо ввести информацию о нем сразу в несколько приложений Банка. Внедрение MDM позволяет избежать создания множества интеграций «точка-точка» между приложениями, и проработки множества возможных вариантов хода бизнес-процесса. При наличии MDM не важно, с какой целью первоначально обратился клиент: для оформления кредита или выпуска платежной карты. В любом случае информация, введенная в одну из фронтальных систем, в режиме близком к реальному времени будет распространена в остальные приложения, и повторно вводить ее в других системах не потребуется.
Аналитические витрины являются потребителями информации, своевременно получая обновления эталонных данных. Это помогает достижению другой цели проекта MDM – формированию надежного массива данных для анализа и использования в моделях ML.
Появление центральной платформы управления данными позволяет начать внедрение приложений нового типа – дата-центрических приложений. Они представляют собой пользовательские интерфейсы, предназначенные для выполнения конкретных задач в рамках тех или иных бизнес-процессов. Эти приложения не имеют собственной СУБД: вместо этого они используют платформу управления данными и хранящиеся в ней эталонные данные как единственный источник информации. Это позволяет существенно сократить время на разработку и внедрение таких приложений, избежать сложной интеграции.
Дата-центрические приложения должны быть готовы к изменению данных, их структуры и правил обработки со стороны платформы. Этого легко добиться, поскольку все эти виды информации доступны через программный интерфейс платформы (API), в том числе в режиме подписки, когда платформа уведомляет приложения о любых происходящих изменениях. С помощью этого механизма можно сделать приложения адаптивными. Например, при появлении нового свойства клиента программа может автоматически отобразить поле ввода значения этого свойства в карточке клиента, и применить к нему правила валидации, заданные в платформе. Создание приложений таким способом позволяет существенно сэкономить на их поддержке и доработке для реализации новых требований бизнеса, а многие требования реализовывать практически мгновенно.
Например, дата-центрическим можно сделать приложение для онбординга клиентов или инструмент формирования маркетинговых кампаний. В первом случае операционист будет вводить через фронт-энд приложения сведения, необходимые для создания нового клиента во всех бизнес-приложениях. Эта информация будет записываться напрямую в платформу управления данными, а сформированный эталонный объект практически мгновенно будет передан во все приложения, отвечающие за выполнение конкретных бизнес-процессов. Во втором случае маркетолог сможет использовать для подбора сегментов клиентов для маркетинговых воздействий полную информацию о клиенте, собранную из всех возможных источников, и включающую как социально-демографические, так и поведенческие данные клиентов.
При реализации обмена клиентскими данными между платформой управления данными (MDM) и бизнес-приложениями нужно обратить внимание на следующее.
1. После внедрения MDM могут стать не нужными некоторые ранее реализованные потоки обмена «точка-точка» между бизнес-приложениями. Их надо отключить, чтобы избежать распространения информации параллельными путями.
2. В режиме тиражирования данных, описанном выше, важное значение имеет подавление эха. Допустим, в результате изменения данных в системе A был обновлен эталонный объект, который тиражирован в систему B. Изменение данных в системе B будет замечено входящим адаптером платформы. Нужен механизм, который позволит отличить изменение, происшедшее в результате обновления данных о клиенте, инициированное со стороны MDM, от изменений, внесенных пользователем в самом приложении. Не вдаваясь в технические детали, заметим, что в DataVera EKG Platform реализовано несколько вариантов решения этой задачи.
3. При одновременном обновлении данных одного клиента со стороны нескольких систем могут возникать коллизии, которые платформа должна уметь разрешать. Наличие средств прослеживания происхождения данных в платформе позволяет избежать вопросов о том, почему информация, внесенная со стороны какой-либо из систем, не попала в эталонный объект.
4. Для приема данных на стороне бизнес-приложений обычно нужно создавать адаптеры, которые выполняют обновление данных в базе приложения при помощи его собственного SDK или API. Созданием таких адаптеров занимаются специалисты, сопровождающие это приложение. При разработке такого адаптера важно учесть множество моментов, касающихся транзакционности операций обновления, возможности (или невозможности) параллельной обработки нескольких запросов на обновление, способности адаптера выдерживать прогнозируемую нагрузку, поддержки целостности данных, правильного информирования платформы о возникших ошибках.
5. При проектировании обмена данными с MDM важно учесть возможность временной недоступности систем-источников и приемников информации. Платформа и адаптеры должны автоматически приводить данные в консистентное состояние после восстановления доступности систем.
6. Платформа должна развертываться в среде, обеспечивающей отказоустойчивость и горизонтальное масштабирование, такой как Kubernetes. Хранилища данных, используемые MDM-системой, также должны быть кластеризованы и обеспечивать отказоустойчивость.
Методология выполнения проекта по внедрению MDM
Внедрение MDM – сложная организационная задача, затрагивающая и трансформирующая ключевые бизнес-процессы Банка. Для успеха внедрения необходимо строго придерживаться практик управления проектами, заключающихся в декомпозиции задач, постоянном контроле прогресса, распределении ресурсов и др. Опишем ключевые моменты, важные для проектов по внедрению MDM.
1. Проект должен быть разбит на спринты, каждый из которых дает полезный и пригодный к использованию результат. Первым шагом должно быть создание корпоративной модели эталонных данных, которая имеет ценность для аналитиков. Вторым шагом, после настройки процедур загрузки данных из источников – формирование метрик качества данных в каждом источнике и списка конкретных нарушений, что позволяет приступить к работе по коррекции данных в источниках. На третьем шаге, после формирования первоначального набора эталонных записей, появляется возможность строить аналитику по клиентской базе, важную для бизнес-подразделений, и так далее. Наличие таких результатов обеспечивает постоянный интерес к проекту и его поддержку со стороны руководства.
2. Выполнение большинства задач в рамках проекта требует тесного взаимодействия между сотрудниками бизнес-подразделений, бизнес-аналитиками, системными аналитиками и интегратором, внедряющим платформу. Необходимость своевременно выделять значительные ресурсы сотрудников Банка и управлять ими требует назначения руководителя проекта со стороны заказчика, обладающего полномочиями для доступа к таким ресурсам. Недостаток этих ресурсов на любой фазе проекта может стать причиной существенного снижения качества результатов проекта.
3. Внедрение MDM – очень сложный проект, состоящий из мозаики технологий, процессов, артефактов и программных решений. Для эффективного управления проектом, понимания его результатов и обеспечения возможности их использовать требуется обозримость проекта и высокая степень информированности всех участников не только о тех участках работы, на котором задействован каждый из них, но и о проекте в целом. Необходимость проводить презентации и общие собрания приводит к росту доли «накладных расходов» в трудозатратах участников проекта, но без этого нельзя обойтись без ущерба для качества.
4. Проектирование и пуско-наладка MDM являются сложными интеллектуальными задачами, требующими системного подхода и коллективной работы разных специалистов. Следует избежать искушения автоматизировать создание эталонной модели данных или правил: все проектные решения должны принимать только эксперты, и только по результатам обсуждения и согласования. Любое проектное решение должно быть обосновано и зафиксировано. В противном случае результаты работы системы будут не объяснимы для бизнес-пользователей, снизится доверие к данным и сократятся возможности их полезного использования.
5. В ходе проекта должна формироваться документация и/или база знаний по нему. На создание таких ресурсов по окончании проекта, скорее всего, не будет времени. К тому же, многие элементы знаний, подлежащие фиксации, нужно записывать «по горячим следам», пока фокус внимания не перешел на другие вопросы.
6. Огромную роль в выполнении проекта играет функциональное, нагрузочное, интеграционное тестирование. Задачи тестирования обычно составляют более половины трудоемкости проекта. Это связано с тем, что сценарии обмена данными с MDM имеют большую вариативность, а также с необходимостью регресс-тестов после каждого изменения правил и настроек. Процессы тестирования необходимо автоматизировать, но доля ручного труда в них все равно остается высокой. В тестировании должны участвовать сотрудники бизнес-подразделений и аналитики, вместе с ИТ-специалистами заказчика и интегратора.
