Александр Нечайкин, начальник Управления архитектуры и эксплуатации приложений, «Пробизнесбанк», ФГ «Лайф»
В современных крупных корпорациях используется множество информационных систем, функции которых зачастую переплетаются друг с другом, а иногда и полностью дублируются, что приводит к избыточности и лишним расходам. В дополнение к стандартным системам, обладающим прозрачными и понятными функциями, существуют узкоспециализированные системы, чьи функции не являются стандартом для информационных систем в больших компаниях. Одной из таких систем выступает MDM – Master Data Management.
С чего все начинается
Важным элементом функционирования компании является постоянная оценка результатов ее деятельности. С помощью точных и оперативных отчетов можно быстро реагировать на изменения бизнеса и корректировать стратегические решения. В небольшой компании, где используется не много информационных систем, ведущих учет деятельности, и не слишком широк ассортимент предоставляемых услуг, обработать результаты систем не составляет труда. Однако по мере роста компании и увеличения спектра ее услуг и учетных систем появляются проблемы, связанные с согласованностью данных и сведением этих данных в одну полноценную картину для руководства компании. Нередко проблема заключается не в получении отдельных отчетов по каждой системе, а в их взаимосвязи между собой. Такими связями выступают справочники, которые ведутся во всех системах и по параметрам которых обычно строится внутренняя отчетность. Даже небольшие ошибки ввода информации приводят к тому, что алгоритмы построения отчетности не видят часть данных. В результате расчетные параметры отображаются некорректно. От этого страдают сотрудники, которые могут недополучить бонусы, и сама компания, которая может потерять ежеминутную прибыль, если примет решение на основе неверного отчета. Последствия для компании могут быть гораздо серьезнее, если на основе такого отчета будет принято долгосрочное решение.
Осознание важности данной проблемы, как правило, происходит не сразу, а с ростом компании и увеличением количества ошибок в отчетности. Чем больше компания, тем сложнее отчеты и тем более основательными становятся стратегические решения, которые строятся на их основе. Эту проблему обычно решают двумя способами. Рассмотрим их подробнее.
Первое решение
При первых проявлениях проблемы обычно пробуют назначить одну из систем источником информации, или так называемой мастер-системой по конкретному справочнику, а остальные системы обязывают получать информацию от мастер-системы. Пока систем немного, конкуренции между ними за структуру справочника нет, сложность самих справочников невысока и структура достаточна для бизнеса, такое решение является наиболее эффективным и экономически обоснованным. Его плюсы очевидны: вместо дополнительных внедрений нужно всего лишь немного доработать мастер-систему. Что касается минусов, то на текущем этапе они не очевидны.
С увеличением количества систем и с повышением их сложности и сегментации бизнеса начинают возникать проблемы: в справочники добавляются все новые функции, растет сложность и самих справочников, и завязанных на них алгоритмов в системах. Вместе с этим возрастает цена сбоя в процессе ведения такого справочника. Кроме того, что назначенный мастер может достигнуть предела своей модификации по данному справочнику, начинают возникать конфликты между интересами систем в архитектуре справочника, а также в методах его ведения. Если свободы у владельцев систем много, то они могут создать конкурирующие мастер-системы. При этом конфликты данных никто не решает, все отвечают за свой небольшой сегмент (модифицированную копию) работы. За весь справочник сквозь все системы ответственности никто не несет.
В итоге получается, что ошибки в отчетности встречаются все чаще, затраты на разработку нового функционала в мастер-системе растут, равно как и расходы на персонал, отвечающий за копии справочника. Именно здесь и происходит осознание того, что нужно выбирать второй способ решения проблемы, более затратный при первичном анализе, но гарантирующий бесперебойную работу процесса, а следовательно, и минимизацию бизнес-потерь.
Финансовая Группа «Лайф» прошла все перечисленные стадии развития и также пришла к выводу, что необходимы единый центр компетенции по данному вопросу и отдельная система, ответственная за единство справочников и гарантирующая их актуальность.
Второе решение
Одним из готовых решений является MDM, или система управления справочными данными. Стоит отметить, что под MDM также понимается целый класс систем, которые могут существенно отличаться друг от друга по множеству параметров, а не только по названию вендора. Набор этих параметров оказывает большое влияние и на цену решения, и на его производительность. При сравнении рыночных предложений перед выбором решения необходимо учитывать все нюансы. Самыми простыми примерами таких классификаций могут быть типы справочников, которые надо обрабатывать (отличаются по подходу к хранению копий «золотой записи» и требуемой скорости обработки записи либо по степени взаимоотношения с информацией): является ли MDM хабом или это единый мастер; происходит ли обогащение данных или просто их перераспределение; участвует ли MDM в операционных потоках информации.
Обобщенная структура системы MDM
На рисунке представлен вариант обобщенной структуры MDM-системы. Некоторые блоки могут относиться не к MDM, а к транспортной системе или же находиться на конечных системах, но так или иначе их необходимо четко выделить и при проектировании определить, где именно они расположены. Чтобы лучше понять, за что отвечает каждый блок и как протекает процесс движения и преобразования информации во всех блоках, рассмотрим пример на основе наиболее комплексного справочника – «Клиенты».
В нашем примере для такого справочника могут существовать следующие источники событий:
- ввод информации с MDM, если такое предусмотрено бизнес-процессом в организации;
- информация из одной из систем источников;
- обновление данных из файла, который сформировала некая система за интервал времени.
Рассмотрим второй вариант, когда данные пришли из одной из систем источников. Предположим, что в нашем примере есть всего три системы с клиентами, каждая из которых является источником информации. Причем пришедшая запись в системе-источнике заведена как новая.
- Этап перекодировки (см. рисунок, блок 1). Вначале все сопроводительные справочники должны быть приведены к единой кодировке, понятной системе MDM. Суть блока можно пояснить на простом примере: в разных системах существует разная кодировка атрибута «пол», и если от системы в поле «пол» пришло 1 или 0, то блок переведет эти значения для другой системы в M и F, а для третьей в М и Ж. Таким образом, данный блок отвечает за то, чтобы сопровождающие списковые справочники могли всегда перекодироваться в значения, понятные MDM, и обратно. Чем сложнее основной справочник, тем выше зависимость от таких сопровождающих справочников и тем больше заметна зависимость от скорости актуализации в них данных.
- Этап очистки данных (2). Каждый атрибут вновь пришедшей записи проходит очистку согласно настроенным алгоритмам для данного поля. Алгоритмы, относящиеся к указанному блоку, обеспечивают максимально возможную степень автоматического исправления ошибок, которую допустили при внесении новых данных. Примерами таких алгоритмов могут служить следующие правки:
- замена букв на похожие по написанию цифры, и обратно;
- замена букв, набранных не в той кодировке;
- удаление лишних пробелов или непечатных символов;
- удаление символов, которые не должны встречаться в данном поле (например, когда ожидаются цифры, а приходят еще и буквы).
- Определение допустимости значения, находящегося в данном поле. Если значение недопустимое, то анализируется степень влияния этого атрибута на смысл записи и принимается решение, стоит ли идти дальше по алгоритму или нужно отбраковать запись и оставить на анализ датастюардам. Все эти операции определяются бизнес-процессом. Например, дата рождения клиента является критически важной, а дата выдачи водительских прав или загранпаспорта может оказаться несущественной.
- Этап обогащения данных (2). Этот блок отвечает за дополнение данных новыми параметрами на основе уже введенных. Такие обогащающие справочники предоставляют внешние компании, специализирующиеся на какой-то конкретной сфере деятельности. В нашем примере выполняются только разбор адреса и простановка кодов КЛАДР.
- Работа с механизмом определения и слияния дублей (3, 4, 5), т. е. вновь пришедшая запись сравнивается с «золотыми записями», которые находятся в MDM по бизнес-ключам. Обычно составляют несколько бизнес-ключей. Степень совпадения по их общему количеству определяет, являются ли сравниваемые записи 100%-ными дублями, или полностью отличаются, или относятся к «серой зоне».
Отметим, что «золотыми» называют те записи, которые были соединены из множества источников в единую запись согласно правилам объединения (4) по важности систем/отдельных атрибутов или актуальности. «Серой зоной» называют записи, которые совпали между собой лишь по части ключей. Разбор такой зоны ложится на плечи датастюардов, которые должны в конечном итоге определить, эта запись единая или нет.
Допустим, в нашем примере было установлено, что записи совпадают не по всем бизнес-ключам и отправляются на ручной разбор.
- Датастюард, отвечающий за разбор конфликтных ситуаций, принимает решение, являются записи одинаковыми или нет. Если, предположим, он видит, что в одном из примеров дата рождения и месяц переставлены местами, и понимает, что перед ним один и тот же клиент, то записи нужно объединять и запускать процесс дальше.
- В этот момент алгоритмы согласно заложенным правилам должны соединить записи по атрибутам.
Варианты могут быть разными, их выбор зависит от конкретного бизнес-процесса. При реализации проекта в ФГ «Лайф» мы ориентировались на приоритет системы и правильность заполнения атрибута. Если количественные оценки этих параметров совпадали, то анализировали время обновления атрибута.
- Когда записи объединены, необходимо распространить новую информацию в конечные системы. Проводится анализ настроек распространения данных (6) в конечные системы. Например, пусть будет установлено, что в одну систему нужно распространить данные в режиме онлайн, а в другую – отправить сообщение только ночью. Запись для ночной системы становится в очередь и ожидает своего времени. Запись для системы, подлежащей немедленной актуализации, проходит через блок перекодировки, приводя коды сопровождающих справочников в понятные для конечной системы, и отправляется в систему назначения. Ночью уходят и остальные изменения, стоявшие на очереди.
Вариантов реализации множество, как и подводных камней, которые встречаются при реализации алгоритмов.
Кратко опишем блоки, которые не были перечислены в приведенном примере, но присутствуют на схеме:
- пользовательский интерфейс системы MDM (7). Все MDM-системы имеют такой блок, но в зависимости от типа данных и степени взаимодействия с MDM к нему предъявляются разные требования. В рамках проекта в ФГ «Лайф» приоритетом было предоставление легкоговеб-интерфейса с единой аутентификацией без цикла согласования. Основными пользователями были датастюарды и ответственные за ведение справочников;
- батчевые процессы (8). Основная цель этого блока – выполнение сложных вычислений, требующих больших вычислительных мощностей, которые нужно производить на некой регулярной основе в технологические окна;
- cистемы инфраструктуры компании (9). Системы, которые являются и источниками, и потребителями информации;
- источники обогащения данных (10). Как правило, это источники информации, находящиеся вне рамок компании и используемые для обогащения информации, например КЛАДР. Другим вариантом данных источников может служить пример, когда сам справочник поставляется внешним регулятором (например, курсы валют);
- источники информации для блочной загрузки (11). Это могут быть и FTP-серверы с файлами, и расшаренные папки, и др.;
- бизнес-процесс заведения информации через MDM. Это информация, которую вносят бизнес-пользователи в систему MDM через ее интерфейс (7).
Ответственность и мониторинг
Главное в данном решении не система, а ответственность датастюардов за актуальную информацию во всех системах. Они должны быть убеждены, что не только в MDM, но и во всех системах все работает. Сама же система MDM – это лишь автоматизированный механизм, который оперативно выполняет заложенные алгоритмы. В случае справочника «Клиенты» на датастюардов ложится еще больше ответственности за постоянное улучшение качества данных в системах, выявление системных ошибок в первичных системах и инициацию изменений в этих системах для повышения или поддержания качества данных.
Сложность состоит еще и в том, что датастюарды помимо технических ошибок должны анализировать данные с точки зрения бизнес-смысла, проверять адекватность и отслеживать тенденции в их изменении. Одним из примеров может служить какое-нибудь необязательное поле, которое согласно статистике заполняется в 80% случаях. Если вдруг на протяжении некоего периода происходит снижение процента заполнения, то стоит инициализировать выяснение причины деградации данных.
Таким образом, чтобы датастюарды могли эффективно выполнять свою работу, необходимо организовать систему мониторинга и развивать ее в двух направлениях:
- мониторинг гарантированной доставки данных и отслеживание конфликтов;
- бизнес-отчеты для своевременного реагирования на деградацию данных.
Узкоспециализированные системы при всей своей ограниченной функциональности характеризуются множеством внутренних особенностей, которые не только оказывают сильное влияние на эту систему, но и видоизменяют всю инфраструктуру компании. Как показывает пример системы MDM, в зависимости от типа указанной системы в организации происходит корректировка ответственности между системами, изменяются маршруты движения данных, а также временные параметры актуализации информации. Помимо прозрачности в структуре с внедрением системы открываются и новые перспективы, связанные с использованием чистых данных. В ФГ «Лайф» появилась возможность сводить всю информацию по разрозненным справочникам воедино, выявлять и описывать логически законченные объекты справочника, такие как «Клиент», «Сотрудник», «Контрагент». Это позволяет быстро подключать новые модули, обеспечивающие старт новых сфер бизнеса, что сокращает время реализации проектов в группе компаний.
